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Abstract 


This document specifies a RObust Header Compression (ROHC) profile 
for compression of TCP/IP packets. The profile, called ROHC-TCP, 
provides efficient and robust compression of TCP headers, including 
frequently used TCP options such as selective acknowledgments (SACKs) 
and Timestamps. 


ROHC-TCP works well when used over links with significant error rates 
and long round-trip times. For many bandwidth-limited links where 
header compression is essential, such characteristics are common. 


This specification obsoletes RFC 4996. It fixes a technical issue 
with the SACK compression and clarifies other compression methods 
used. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6846. 
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Introduction 


There are several reasons to perform header compression on low- or 
medium-speed links for TCP/IP traffic, and these have already been 
discussed in [RFC2507]. Additional considerations that make 
robustness an important objective for a TCP [RFCO793] compression 
scheme are introduced in [RFC4163]. Finally, existing TCP/IP header 
compression schemes ([RFC1144], [RFC2507]) are limited in their 
handling of the TCP options field and cannot compress the headers of 
handshaking packets (SYNs and FINs). 


It is thus desirable for a header compression scheme to be able to 
handle loss on the link between the compression and decompression 
points as well as loss before the compression point. The header 
compression scheme also needs to consider how to efficiently compress 
short-lived TCP transfers and TCP options, such as selective 
acknowledgments (SACK) ([RFC2018], [RFC2883]) and Timestamps 
([RFC1323]). TCP options that may be less frequently used do not 
necessarily need to be compressed by the protocol, and instead can be 
passed transparently without reducing the overall compression 
efficiency of other parts of the TCP header. 


The Robust Header Compression (ROHC) Working Group has developed a 
header compression framework on top of which various profiles can be 
defined for different protocol sets, or for different compression 
strategies. This document defines a TCP/IP compression profile for 
the ROHC framework [RFC5795], compliant with the requirements listed 
in [RFC4163]. 


Specifically, it describes a header compression scheme for TCP/IP 
header compression (ROHC-TCP) that is robust against packet loss and 
that offers enhanced capabilities, in particular for the compression 
of header fields including TCP options. The profile identifier for 
TCP/IP compression is 0x0006. 


Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


This document reuses some of the terminology found in [RFC5795]. In 
addition, this document uses or defines the following terms: 
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Base context 


The base context is a context that has been validated by both the 
compressor and the decompressor. A base context can be used as 
the reference when building a new context using replication. 


Base Context Identifier (Base CID) 


The Base CID is the CID that identifies the base context, from 
which information needed for context replication can be extracted. 


Base header 


The Base header is a compressed representation of the innermost IP 
and TCP headers of the uncompressed packet. 


Chaining of items 


A chain groups fields based on similar characteristics. ROHC-TCP 
defines chain items for static, dynamic, replicable, or irregular 
fields. Chaining is done by appending an item for each header, 
e.g., to the chain in their order of appearance in the 
uncompressed packet. Chaining is useful to construct compressed 
headers from an arbitrary number of any of the protocol headers 
for which ROHC-TCP defines a compressed format. 


Context Replication (CR) 


Context replication is the mechanism that establishes and 
initializes a new context based on another existing valid context 
(a base context). This mechanism is introduced to reduce the 
overhead of the context establishment procedure, and is especially 
useful for compression of multiple short-lived TCP connections 
that may be occurring simultaneously or near-simultaneously. 


ROHC-TCP packet types 


ROHC-TCP uses three different packet types: the Initialization and 
Refresh (IR) packet type, the Context Replication (IR-CR) packet 
type, and the Compressed packet (CO) type. 


Short-lived TCP transfer 


Short-lived TCP transfers refer to TCP connections transmitting 
only small amounts of packets for each single connection. 
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Background 


This section provides some background information on TCP/IP header 
compression. The fundamentals of general header compression can be 
found in [RFC5795]. In the following subsections, two existing 
TCP/IP header compression schemes are first described along with a 
discussion of their limitations, followed by the classification of 
TCP/IP header fields. Finally, some of the characteristics of short- 
lived TCP transfers are summarized. 


A behavior analysis of TCP/IP header fields is found in [RFC4413]. 


Existing TCP/IP Header Compression Schemes 


Compressed TCP (CTCP) and IP Header Compression (IPHC) are two 
different schemes that may be used to compress TCP/IP headers. Both 
schemes transmit only the differences from the previous header in 
order to reduce the size of the TCP/IP header. 


The CTCP [RFC1144] compressor detects transport-level retransmissions 
and sends a header that updates the context completely when they 
occur. While CTCP works well over reliable links, it is vulnerable 
when used over less reliable links as even a single packet loss 
results in loss of synchronization between the compressor and the 
decompressor. This in turn leads to the TCP receiver discarding all 
remaining packets in the current window because of a checksum error. 
This effectively prevents the TCP fast retransmit algorithm [RFC5681] 
from being triggered. In such a case, the compressor must wait until 
TCP times out and retransmits a packet to resynchronize. 


To reduce the errors due to the inconsistent contexts between 
compressor and decompressor when compressing TCP, IPHC [RFC2507] 
improves somewhat on CTCP by augmenting the repair mechanism of CTCP 
with a local repair mechanism called TWICE and with a link-layer 
mechanism based on negative acknowledgments to request a header that 
updates the context. 


The TWICE algorithm assumes that only the Sequence Number field of 
TCP segments is changing with the deltas between consecutive packets 
being constant in most cases. This assumption is, however, not 
always true, especially when TCP Timestamps and SACK options are 
used. 


The full header request mechanism requires a feedback channel that 
may be unavailable in some circumstances. This channel is used to 
explicitly request that the next packet be sent with an uncompressed 
header to allow resynchronization without waiting for a TCP timeout. 
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In addition, this mechanism does not perform well on links with long 
round-trip times. 


Both CTCP and IPHC are also limited in their handling of the TCP 
options field. For IPHC, any change in the options field (caused by 
Timestamps or SACK, for example) renders the entire field 
uncompressible, while for CTCP, such a change in the options field 
effectively disables TCP/IP header compression altogether. 


Finally, existing TCP/IP compression schemes do not compress the 
headers of handshaking packets (SYNs and FINS). Compressing these 
packets may greatly improve the overall header compression ratio for 
the cases where many short-lived TCP connections share the same 
channel. 


3.2. Classification of TCP/IP Header Fields 


Header compression is possible due to the fact that there is much 
redundancy between header field values within packets, especially 
between consecutive packets. To utilize these properties for TCP/IP 
header compression, it is important to understand the change patterns 
of the various header fields. 


All fields of the TCP/IP packet header have been classified in detail 
in [RFC4413]. The main conclusion is that most of the header fields 
can easily be compressed away since they seldom or never change. The 
following fields do, however, require more sophisticated mechanisms: 


- IPv4 Identification (16 bits) - IP-ID 
- TCP Sequence Number (32 bits) - SN 
- TCP Acknowledgment Number (32 bits) 
- TCP Reserved ( 4 bits) 
- TCP ECN flags ( 2 bits) - ECN 
- TCP Window (16 bits) 
- TCP Options 
o Maximum Segment Size (32 bits) - MSS 
o Window Scale (24 bits) - WSCALE 
o SACK Permitted (16 bits) 
o TCP SACK (80, 144, 208, or 272 bits) - SACK 
o TCP Timestamp (80 bits) - TS 


The assignment of IP-ID values can be done in various ways, usually 
one of sequential, sequential jump, or random, as described in 
Section 4.1.3 of [RFC4413]. Some IPv4 stacks do use a sequential 
assignment when generating IP-ID values but do not transmit the 
contents of this field in network byte order; instead, it is sent 
with the two octets reversed. In this case, the compressor can 
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compress the IP-ID field after swapping the bytes. Consequently, the 
decompressor also swaps the bytes of the IP-ID after decompression to 
regenerate the original IP-ID. With respect to TCP compression, the 
analysis in [RFC4413] reveals that there is no obvious candidate 
among the TCP fields suitable to infer the IP-ID. 


The change pattern of several TCP fields (Sequence Number, 
Acknowledgment Number, Window, etc.) is very hard to predict. Of 
particular importance to a TCP/IP header compression scheme is the 
understanding of the sequence and acknowledgment numbers [RFC4413]. 


Specifically, the TCP Sequence Number can be anywhere within a range 
defined by the TCP Window at any point on the path (i.e., wherever a 
compressor might be deployed). Missing packets or retransmissions 
can cause the TCP Sequence Number to fluctuate within the limits of 
this window. The TCP Window also bounds the jumps in acknowledgment 
number. 


Another important behavior of the TCP/IP header is the dependency 
between the sequence number and the acknowledgment number. TCP 
connections can be either near-symmetrical or show a strong 
asymmetrical bias with respect to the data traffic. In the latter 
case, the TCP connections mainly have one-way traffic (Web browsing 
and file downloading, for example). This means that on the forward 
path (from server to client), only the sequence number is changing 
while the acknowledgment number remains constant for most packets; on 
the backward path (from client to server), only the acknowledgment 
number is changing and the sequence number remains constant for most 
packets. A compression scheme for TCP should thus have packet 
formats suitable for either cases, i.e., packet formats that can 
carry either only sequence number bits, only acknowledgment number 
bits, or both. 


In addition, TCP flows can be short-lived transfers. Short-lived TCP 
transfers will degrade the performance of header compression schemes 
that establish a new context by initially sending full headers. 
Multiple simultaneous or near simultaneous TCP connections may 
exhibit much similarity in header field values and context values 
among each other, which would make it possible to reuse information 
between flows when initializing a new context. A mechanism to this 
end, context replication [RFC4164], makes the context establishment 
step faster and more efficient, by replicating part of an existing 
context to a new flow. The conclusion from [RFC4413] is that part of 
the IP sub-context, some TCP fields, and some context values can be 
replicated since they seldom change or change with only a small jump. 
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ROHC-TCP also compresses the following headers: IPv6 Destination 
Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by- 
Hop Options header [RFC2460], Authentication Header (AH) [RFC4302], 
Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890], and the 
Minimal Encapsulation (MINE) header [RFC2004]. 


Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any 
special treatment in this document, for reasons similar to those 
described in [RFC3095]. 


4. Overview of the TCP/IP Profile (Informative) 

4.1. General Concepts 
ROHC-TCP uses the ROHC protocol as described in [RFC5795]. ROHC-TCP 
supports context replication as defined in [RFC4164]. Context 
replication can be particularly useful for short-lived TCP flows 
[RFC4413]. 

4.2. Compressor and Decompressor Interactions 

4.2.1. Compressor Operation 


Header compression with ROHC can be conceptually characterized as the 
interaction of a compressor with a decompressor state machine. The 
compressor’s task is to minimally send the information needed to 
successfully decompress a packet, based on a certain confidence 
regarding the state of the decompressor context. 


For ROHC-TCP compression, the compressor normally starts compression 
with the initial assumption that the decompressor has no useful 
information to process the new flow, and sends Initialization and 
Refresh (IR) packets. Alternatively, the compressor may also support 
Context Replication (CR) and use IR-CR packets [RFC4164], which 
attempts to reuse context information related to another flow. 


The compressor can then adjust the compression level based on its 
confidence that the decompressor has the necessary information to 
successfully process the Compressed (CO) packets that it selects. In 
other words, the task of the compressor is to ensure that the 
decompressor operates in the state that allows decompression of the 
most efficient CO packet(s), and to allow the decompressor to move to 
that state as soon as possible otherwise. 
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4.2.2. Decompressor Feedback 


The ROHC-TCP profile can be used in environments with or without 
feedback capabilities from decompressor to compressor. ROHC-TCP, 
however, assumes that if a ROHC feedback channel is available and if 
this channel is used at least once by the decompressor for a specific 
ROHC-TCP context, this channel will be used during the entire 
compression operation for that context. If the feedback channel 
disappears, compression should be restarted. 


The reception of either positive acknowledgments (ACKs) or negative 
acknowledgments (NACKs) establishes the feedback channel from the 
decompressor for the context for which the feedback was received. 
Once there is an established feedback channel for a specific context, 
the compressor should make use of this feedback to estimate the 
current state of the decompressor. This helps in increasing the 
compression efficiency by providing the information needed for the 
compressor to achieve the necessary confidence level. 


The ROHC-TCP feedback mechanism is limited in its applicability by 
the number of (least significant bit (LSB) encoded) master sequence 
number (MSN) (see Section 6.1.1) bits used in the FEEDBACK-2 format 
(see Section 8.3). It is not suitable for a decompressor to use 
feedback altogether where the MSN bits in the feedback could wrap 
around within one round-trip time. Instead, unidirectional operation 
-- where the compressor periodically sends larger context-updating 
packets -- is more appropriate. 


4.3. Packet Formats and Encoding Methods 


The packet formats and encoding methods used for ROHC-TCP are defined 
using the formal notation [RFC4997]. The formal notation is used to 
provide an unambiguous representation of the packet formats and a 
clear definition of the encoding methods. 


4.3.1. Compressing TCP Options 


The TCP options in ROHC-TCP are compressed using a list compression 
encoding that allows option content to be established so that TCP 
options can be added to the context without having to send all TCP 
options uncompressed. 


4.3.2. Compressing Extension Headers 


ROHC-TCP compresses the extension headers as listed in Section 3.2. 
These headers are treated exactly as other headers and thus have a 
static chain, a dynamic chain, an irregular chain, and a chain for 
context replication (Section 6.2). 
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This means that headers appearing in or disappearing from the flow 
being compressed will lead to changes to the static chain. However, 
the change pattern of extension headers is not deemed to impair 
compression efficiency with respect to this design strategy. 


4.4. Expected Compression Ratios with ROHC-TCP 


The following table illustrates typical compression ratios that can 
be expected when using ROHC-TCP and IPHC [RFC2507]. 


The figures in the table assume that the compression context has 
already been properly initialized. For the TS option, the Timestamp 
is assumed to change with small values. All TCP options include a 
suitable number of No Operation (NOP) options [RFCO793] for padding 
and/or alignment. Finally, in the examples for IPv4, a sequential 
IP-ID behavior is assumed. 


Total Header Size (octets) 


ROHC-TCP IPHC 
Unc. DATA ACK DATA ACK 
IPv4+TCP+TS 52 8 8 18 18 
IPv4+TCP+TS 52 7 6 16 16 (1) 
IPv6+TCP+TS 72 8 E 18 18 
IPv6+TCP+no opt 60 6 5 6 6 
IPv6+TCP+SACK 80 > 15 = 80 (2) 
IPv6+TCP+SACK 80 = 9 = 26 (3) 


(1) The payload size of the data stream is constant. 

(2) The SACK option appears in the header, but was not present 
in the previous packet. Two SACK blocks are assumed. 

(3) The SACK option appears in the header, and was also present 
in the previous packet (with different SACK blocks). 
Two SACK blocks are assumed. 


The table below illustrates the typical initial compression ratios 
for ROHC-TCP and IPHC. The data stream in the example is assumed to 
be IPv4+TCP, with a sequential behavior for the IP-ID. The following 
options are assumed present in the SYN packet: TS, MSS, and WSCALE, 
with an appropriate number of NOP options. 


Total Header Size (octets) 


Unc. ROHC-TCP IPHC 
Ist packet (SYN) 60 49 60 
2nd packet 52 12 52 


The figures in the table assume that the compressor has received an 
acknowledgment from the decompressor before compressing the second 
packet, which can be expected when feedback is used in ROHC-TCP. 
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This is because in the most common case, the TCP ACKs are expected to 
take the same return path, and because TCP does not send more packets 
until the TCP SYN packet has been acknowledged. 


5. Compressor and Decompressor Logic (Normative) 
5.1. Context Initialization 

The static context of ROHC-TCP flows can be initialized in either of 

two ways: 

1. By using an IR packet as in Section 7.1, where the profile number 
is 0x06 and the static chain ends with the static part of a TCP 
header. 

2. By replicating an existing context using the mechanism defined by 
[RFC4164]. This is done with the IR-CR packet defined in 
Section 7.2, where the profile number is 0x06. 

5.2. Compressor Operation 
ou Compression Logic 


The task of the compressor is to determine what data must be sent 
when compressing a TCP/IP packet, so that the decompressor can 
successfully reconstruct the original packet based on its current 
state. The selection of the type of compressed header to send thus 
depends on a number of factors, including: 


o 


The change behavior of header fields in the flow, e.g., conveying 
the necessary information within the restrictions of the set of 
available packet formats. 


The compressor's level of confidence regarding decompressor state, 
e.g., by selecting header formats updating the same type of 
information for a number of consecutive packets or from the 
reception of decompressor feedback (ACKs and/or NACKs). 


Additional robustness required for the flow, e.g., periodic 
refreshes of static and dynamic information using IR and IR-DYN 
packets when decompressor feedback is not expected. 


The impact of these factors on the compressor's packet type selection 
is described in more detail in the following subsections. 
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In this section, a "higher compression state" means that less data 
will be sent in compressed packets, i.e., smaller compressed headers 
are used, while a lower compression state means that a larger amount 
of data will be sent using larger compressed headers. 


5.2.1.1. Optimistic Approach 


The optimistic approach is the principle by which a compressor sends 
the same type of information for a number of packets (consecutively 
or not) until it is fairly confident that the decompressor has 
received the information. The optimistic approach is useful to 
ensure robustness when ROHC-TCP is used to compress packets over 
lossy links. 


Therefore, if field X in the uncompressed packet changes value, the 
compressor MUST use a packet type that contains an encoding for field 
X until it has gained confidence that the decompressor has received 
at least one packet containing the new value for X. The compressor 
SHOULD choose a compressed format with the smallest header that can 
convey the changes needed to fulfill the optimistic approach 
condition used. 


5.2.1.2. Periodic Context Refreshes 


When the optimistic approach is used, there will always be a 
possibility of decompression failures since the decompressor may not 
have received sufficient information for correct decompression. 


Therefore, until the decompressor has established a feedback channel, 
the compressor SHOULD periodically move to a lower compression state 
and send IR and/or IR-DYN packets. These refreshes can be based on 
timeouts, on the number of compressed packets sent for the flow, or 
any other strategy specific to the implementation. Once the feedback 
channel is established, the decompressor MAY stop performing periodic 
refreshes. 


5.2.2. Feedback Logic 
The semantics of feedback messages, acknowledgments (ACKs) and 
negative acknowledgments (NACKs or STATIC-NACKs), are defined in 
Section 5.2.4.1 of [RFC5795]. 

5.2.2.1. Optional Acknowledgments (ACKs) 


The compressor MAY use acknowledgment feedback (ACKs) to move to a 
higher compression state. 
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Upon reception of an ACK for a context-updating packet, the 
compressor obtains confidence that the decompressor has received the 
acknowledged packet and that it has observed changes in the packet 
flow up to the acknowledged packet. 


This functionality is optional, so a compressor MUST NOT expect to 
get such ACKs, even if a feedback channel is available and has been 
established for that flow. 

5.2.2.2. Negative Acknowledgments (NACKs) 


The compressor uses feedback from the decompressor to move to a lower 
compression state (NACKs). 


On reception of a NACK feedback, the compressor SHOULD: 
o assume that only the static part of the decompressor is valid, and 


o re-send all dynamic information (via an IR or IR-DYN packet) the 
next time it compresses a packet for the indicated flow 


unless it has confidence that information sent after the packet being 
acknowledged already provides a suitable response to the NACK 
feedback. In addition, the compressor MAY use a CO packet carrying a 
7-bit Cyclic Redundancy Check (CRC) if it can determine with enough 
confidence what information provides a suitable response to the NACK 
feedback. 


On reception of a STATIC-NACK feedback, the compressor SHOULD: 
o assume that the decompressor has no valid context, and 


o re-send all static and all dynamic information (via an IR packet) 
the next time it compresses a packet for the indicated flow 


unless it has confidence that information sent after the packet that 
is being acknowledged already provides a suitable response to the 
STATIC-NACK feedback. 

5.2.3. Context Replication 


A compressor MAY support context replication by implementing the 
additional compression and feedback logic defined in [RFC4164]. 
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5.3. Decompressor Operation 
5.3.1. Decompressor States and Logic 


The three states of the decompressor are No Context (NC), Static 
Context (SC), and Full Context (FC). The decompressor starts in its 
lowest compression state, the NC state. Successful decompression 
will always move the decompressor to the FC state. The decompressor 
state machine normally never leaves the FC state once it has entered 
this state; only repeated decompression failures will force the 
decompressor to transit downwards to a lower state. 


Below is the state machine for the decompressor. Details of the 
transitions between states and decompression logic are given in the 
subsections following the figure. 


Success 
Ho > >= >= >= >= >--+ 
No Static | No Dynamic Success | Success 
+-->--+ | +-->--+ +--->----- >---+ +-->--+ 
v | v v v 
eea + fo SS SSS EE EEE + ia a n + 
| No Context (NC) | | Static Context (SC) | | Full Context (FC) | 
Bekea + os SE ST + POSE + 
Static Context Context Damage Assumed 
Damage Assumed 
Ho <------ <------ <----- + +-—==== <------ <------ <----- + 
5.3.1.1. Reconstruction and Verification 


When decompressing an IR or an IR-DYN packet, the decompressor MUST 
validate the integrity of the received header using CRC-8 validation 
[RFC5795]. If validation fails, the packet MUST NOT be delivered to 
upper layers. 


Upon receiving an IR-CR packet, the decompressor MUST perform the 
actions as specified in [RFC4164]. 


When decompressing other packet types (e.g., CO packets), the 
decompressor MUST validate the outcome of the decompression attempt 
using CRC verification [RFC5795]. If verification fails, a 
decompressor implementation MAY attempt corrective or repair measures 
on the packet, and the result of any attempt MUST be validated using 
the CRC verification; otherwise, the packet MUST NOT be delivered to 
upper layers. 
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When the CRC-8 validation or the CRC verification of the received 
header is successful, the decompressor SHOULD update its context with 
the information received in the current header; the decompressor then 
passes the reconstructed packet to the system’s network layer. 
Otherwise, the decompressor context MUST NOT be updated. 


If the received packet is older than the current reference packet, 
e.g., based on the master sequence number (MSN) in the compressed 
packet, the decompressor MAY refrain from updating the context using 
the information received in the current packet, even if the 
correctness of its header was successfully verified. 


5.3.1.2. Detecting Context Damage 


All header formats carry a CRC and are context updating. A packet 
for which the CRC succeeds updates the reference values of all header 
fields, either explicitly (from the information about a field carried 
within the compressed header) or implicitly (fields that are inferred 
from other fields). 


The decompressor may assume that some or the entire context is 
invalid, following one or more failures to validate or verify a 
header using the CRC. Because the decompressor cannot know the exact 
reason(s) for a CRC failure or what field caused it, the validity of 
the context hence does not refer to what exact context entry is 
deemed valid or not. 


Validity of the context rather relates to the detection of a problem 
with the context. The decompressor first assumes that the type of 
information that most likely caused the failure(s) is the state that 
normally changes for each packet, i.e., context damage of the dynamic 
part of the context. Upon repeated failures and unsuccessful 
repairs, the decompressor then assumes that the entire context, 
including the static part, needs to be repaired, i.e., static context 
damage. 


Context Damage Detection 
The assumption of context damage means that the decompressor will 
not attempt decompression of a CO header that carries a 3-bit CRC, 
and only attempt decompression of IR, IR-DYN, or IR-CR headers or 
CO headers protected by a CRC-7. 

Static Context Damage Detection 
The assumption of static context damage means that the 


decompressor refrains from attempting decompression of any type of 
header other than the IR header. 
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How these assumptions are made, i.e., how context damage is detected, 
is open to implementations. It can be based on the residual error 
rate, where a low error rate makes the decompressor assume damage 
more often than on a high-rate link. 


The decompressor implements these assumptions by selecting the type 
of compressed header for which it may attempt decompression. In 
other words, validity of the context refers to the ability of a 
decompressor to attempt or not attempt decompression of specific 
packet types. 


5.3.1.3. No Context (NC) State 


Initially, while working in the No Context (NC) state, the 
decompressor has not yet successfully decompressed a packet. 


Allowing decompression: 


In the NC state, only packets carrying sufficient information on 
the static fields (IR and IR-CR packets) can be decompressed; 
otherwise, the packet MUST NOT be decompressed and MUST NOT be 
delivered to upper layers. 


Feedback logic: 


In the NC state, the decompressor should send a STATIC-NACK if a 
packet of a type other than IR is received, or if decompression of 
an IR packet has failed, subject to the feedback rate limitation 
as described in Section 5.3.2. 


Once a packet has been validated and decompressed correctly, the 
decompressor MUST transit to the FC state. 


5.3.1.4. Static Context (SC) State 


When the decompressor is in the Static Context (SC) state, only the 
static part of the decompressor context is valid. 


From the SC state, the decompressor moves back to the NC state if 
static context damage is detected. 


Allowing decompression: 


In the SC state, packets carrying sufficient information on the 
dynamic fields covered by an 8-bit CRC (e.g., IR and IR-DYN) or CO 
packets covered by a 7-bit CRC can be decompressed; otherwise, the 
packet MUST NOT be decompressed and MUST NOT be delivered to upper 
layers. 
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Feedback logic: 


In the SC state, the decompressor should send a STATIC-NACK if CRC 
validation of an IR/IR-DYN/IR-CR fails and static context damage 
is assumed. If any other packet type is received, the 
decompressor should send a NACK. Both of the above cases are 
subject to the feedback rate limitation as described in 

Section 5.3.2. 


Once a packet has been validated and decompressed correctly, the 
decompressor MUST transit to the FC state. 


5.3.1.5. Full Context (FC) State 


5. 


3 


In the Full Context (FC) state, both the static and the dynamic parts 
of the decompressor context are valid. From the FC state, the 
decompressor moves back to the SC state if context damage is 
detected. 


Allowing decompression: 


In the FC state, decompression can be attempted regardless of the 
type of packet received. 


Feedback logic: 


In the FC state, the decompressor should send a NACK if the 
decompression of any packet type fails and context damage is 
assumed, subject to the feedback rate limitation as described in 
Section 5.3.2. 


-2. Feedback Logic 


The decompressor MAY send positive feedback (ACKs) to initially 
establish the feedback channel for a particular flow. Either 
positive feedback (ACKs) or negative feedback (NACKs) establishes 
this channel. 


Once the feedback channel is established, the decompressor is 
REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the 
context is associated with the same profile, in this case with 
profile 0x0006, as per the logic defined for each state in 

Section 5.3.1. 


The decompressor MAY send ACKs upon successful decompression of any 
packet type. In particular, when a packet carrying a significant 
context update is correctly decompressed, the decompressor MAY send 
an ACK. 
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The decompressor should limit the rate at which it sends feedback, 
for both ACKs and STATIC-NACK/NACKs, and should avoid sending 
unnecessary duplicates of the same type of feedback message that may 
be associated to the same event. 


5.3.3. Context Replication 


ROHC-TCP supports context replication; therefore, the decompressor 
MUST implement the additional decompressor and feedback logic defined 
in [RFC4164]. 


6. Encodings in ROHC-TCP (Normative) 
6.1. Control Fields in ROHC-TCP 


In ROHC-TCP, a number of control fields are used by the decompressor 
in its interpretation of the format of the packets received from the 
compressor. 


A control field is a field that is transmitted from the compressor to 
the decompressor, but is not part of the uncompressed header. Values 
for control fields can be set up in the context of both the 
compressor and the decompressor. Once established at the 
decompressor, the values of these fields should be kept until updated 
by another packet. 


6.1.1. Master Sequence Number (MSN) 


There is no field in the TCP header that can act as the master 
sequence number for TCP compression, as explained in [RFC4413], 
Section 5.6. 


To overcome this problem, ROHC-TCP introduces a control field called 
the Master Sequence Number (MSN) field. The MSN field is created at 
the compressor, rather than using one of the fields already present 
in the uncompressed header. The compressor increments the value of 
the MSN by one for each packet that it sends. 


The MSN field has the following two functions: 


1. Differentiating between packets when sending feedback data. 


2. Inferring the value of incrementing fields such as the IP-ID. 
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The MSN field is present in every packet sent by the compressor. The 
MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent 
in full in IR/IR-DYN packets. The decompressor always sends the MSN 
as part of the feedback information. The compressor can later use 
the MSN to infer which packet the decompressor is acknowledging. 


When the MSN is initialized, it SHOULD be initialized to a random 
value. The compressor should only initialize a new MSN for the 
initial IR or IR-CR packet sent for a CID that corresponds to a 
context that is not already associated with this profile. In other 
words, if the compressor reuses the same CID to compress many TCP 
flows one after the other, the MSN is not reinitialized but rather 
continues to increment monotonically. 


For context replication, the compressor does not use the MSN of the 
base context when sending the IR-CR packet, unless the replication 
process overwrites the base context (i.e., Base CID == CID). 
Instead, the compressor uses the value of the MSN if it already 
exists in the ROHC-TCP context being associated with the new flow 
(CID); otherwise, the MSN is initialized to a new value. 


6.1.2. IP-ID Behavior 


The IP-ID field of the IPv4 header can have different change 
patterns. Conceptually, a compressor monitors changes in the value 
of the IP-ID field and selects encoding methods and packet formats 
that are the closest match to the observed change pattern. 


ROHC-TCP defines different types of compression techniques for the 
IP-ID, to provide the flexibility to compress any of the behaviors it 
may observe for this field: sequential in network byte order (NBO), 
sequential byte-swapped, random (RND), or constant to a value of 
zero. 


The compressor monitors changes in the value of the IP-ID field for a 
number of packets, to identify which one of the above listed 
compression alternatives is the closest match to the observed change 
pattern. The compressor can then select packet formats and encoding 
methods based on the identified field behavior. 


If more than one level of IP headers is present, ROHC-TCP can assign 
a sequential behavior (NBO or byte-swapped) only to the IP-ID of the 
innermost IP header. This is because only this IP-ID can possibly 
have a sufficiently close correlation with the MSN (see also 

Section 6.1.1) to compress it as a sequentially changing field. 
Therefore, a compressor MUST NOT assign either the sequential (NBO) 
or the sequential byte-swapped behavior to tunneling headers. 
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The control field for the IP-ID behavior determines which set of 
packet formats will be used. These control fields are also used to 
determine the contents of the irregular chain item (see Section 6.2) 
for each IP header. 


6.1.3. Explicit Congestion Notification (ECN) 


When ECN [RFC3168] is used once on a flow, the ECN bits could change 
quite often. ROHC-TCP maintains a control field in the context to 
indicate whether or not ECN is used. This control field is 
transmitted in the dynamic chain of the TCP header, and its value can 
be updated using specific compressed headers carrying a 7-bit CRC. 


When this control field indicates that ECN is being used, items of 
all IP and TCP headers in the irregular chain include bits used for 
ECN. To preserve octet-alignment, all of the TCP reserved bits are 
transmitted and, for outer IP headers, the entire Type of Service/ 
Traffic Class (TOS/TC) field is included in the irregular chain. 
When there is only one IP header present in the packet (i.e., no IP 
tunneling is used), this compression behavior allows the compressor 
to handle changes in the ECN bits by adding a single octet to the 
compressed header. 


The reason for including the ECN bits of all IP headers in the 
compressed packet when the control field is set is that the profile 
needs to efficiently compress flows containing IP tunnels using the 
"full-functionality option" of Section 9.1 of [RFC3168]. For these 
flows, a change in the ECN bits of an inner IP header is propagated 
to the outer IP headers. When the "limited-functionality" option is 
used, the compressor will therefore sometimes send one octet more 
than necessary per tunnel header, but this has been considered a 
reasonable trade-off when designing this profile. 


6.2. Compressed Header Chains 


Some packet types use one or more chains containing sub-header 
information. The function of a chain is to group fields based on 
similar characteristics, such as static, dynamic, or irregular 
fields. Chaining is done by appending an item for each header to the 
chain in their order of appearance in the uncompressed packet, 
starting from the fields in the outermost header. 


Chains are defined for all headers compressed by ROHC-TCP, as listed 


below. Also listed are the names of the encoding methods used to 
encode each of these protocol headers. 
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o 


TCP [RFCO793], encoding method: "tcp" 

IPv4 [RFCO791], encoding method: "ipv4" 

IPv6 [RFC2460], encoding method: "ipv6" 

AH [RFC4302], encoding method: "ah" 

GRE [RFC2784] [RFC2890], encoding method: "gre" 
MINE [RFC2004], encoding method: "mine" 


IPv6 Destination Options header [RFC2460], encoding method: 
"ip dest opt" 


IPv6 Hop-by-Hop Options header [RFC2460], encoding method: 
"ip hop opt" 


IPv6 Routing header [RFC2460], encoding method: "ip rout opt" 


Static chain: 


The static chain consists of one item for each header of the chain 
of protocol headers to be compressed, starting from the outermost 
IP header and ending with a TCP header. In the formal description 
of the packet formats, this static chain item for each header is a 
format whose name is suffixed by "_static". The static chain is 
only used in IR packets. 


Dynamic chain: 


The dynamic chain consists of one item for each header of the 
chain of protocol headers to be compressed, starting from the 
outermost IP header and ending with a TCP header. The dynamic 
chain item for the TCP header also contains a compressed list of 


TCP options (see Section 6.3). In the formal description of the 
packet formats, the dynamic chain item for each header type is a 
format whose name is suffixed by "_dynamic". The dynamic chain is 


used in both IR and IR-DYN packets. 


Replicate chain: 


The replicate chain consists of one item for each header in the 
chain of protocol headers to be compressed, starting from the 
outermost IP header and ending with a TCP header. The replicate 
chain item for the TCP header also contains a compressed list of 
TCP options (see Section 6.3). In the formal description of the 
packet formats, the replicate chain item for each header type is a 
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format whose name is suffixed by " replicate". Header fields that 
are not present in the replicate chain are replicated from the 
base context. The replicate chain is only used in the IR-CR 
packet. 


Irregular chain: 


The structure of the irregular chain is analogous to the structure 
of the static chain. For each compressed packet, the irregular 
chain is appended at the specified location in the general format 
of the compressed packets as defined in Section 7.3. This chain 
also includes the irregular chain items for TCP options as defined 
in Section 6.3.6, which are placed directly after the irregular 
chain item of the TCP header, and in the same order as the options 


appear in the uncompressed packet. In the formal description of 
the packet formats, the irregular chain item for each header type 
is a format whose name is suffixed by "_irregular". The irregular 


chain is used only in CO packets. 


The format of the irregular chain for the innermost IP header 
differs from the format of outer IP headers, since this header is 
part of the compressed base header. 


6.3. Compressing TCP Options with List Compression 


This section describes in detail how list compression is applied to 
the TCP options. In the definition of the packet formats for ROHC- 
TCP, the most frequent TCP options have one encoding method each, as 
listed in the table below. 


4+----------------- +------------------------ + 
| Option name | Encoding method name | 
+----------------- +------------------------ + 
NOP tcp_opt_nop 
EOL tcp_opt_eol 
| MSS | tcp_opt_mss 
| WINDOW SCALE | tcp_opt_wscale | 
| TIMESTAMP | tcp_opt_ts | 
| SACK-PERMITTED | tcp_opt_sack_permitted | 
SACK tcp_opt_sack 
Generic options tcp_opt_generic 
+----------------- +------------------------ + 


Each of these encoding methods has an uncompressed format, a format 
suffixed by "_list_item" and a format suffixed by "_irregular". In 
some cases, a Single encoding method may have multiple "_list_item" 
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or " irregular" formats, in which case bindings inside these formats 
determine what format is used. This is further described in the 
following sections. 


6.3.1. List Compression 


The TCP options in the uncompressed packet can be represented as an 
ordered list, whose order and presence are usually constant between 


packets. The generic structure of such a list is as follows: 
+-------- +-------- Ea seren + 
list: | item 1 | item 2 | item n | 
+-------- +-------- +-- --+-------- + 


To compress this list, ROHC-TCP uses a list compression scheme, which 
compresses each of these items individually and combines them into a 
compressed list. 


The basic principles of list-based compression are the following: 


1) When a context is being initialized, a complete representation 
of the compressed list of options is transmitted. All options 
that have any content are present in the compressed list of items 
sent by the compressor. 


Then, once the context has been initialized: 


2) When the structure AND the content of the list are unchanged, 
no information about the list is sent in compressed headers. 


3) When the structure of the list is constant, and when only the 
content defined within the irregular format for one or more 
options is changed, no information about the list needs to be sent 
in compressed base headers; the irregular content is sent as part 
of the irregular chain, as described in Section 6.3.6. 


4) When the structure of the list changes, a compressed list is 
sent in the compressed base header, including a representation of 
its structure and order. Content defined within the irregular 
format of an option can still be sent as part of the irregular 
chain (as described in Section 6.3.6), provided that the item 
content is not part of the compressed list. 
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6. 
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EE 


.2. Table-Based Item Compression 


The table-based item compression compresses individual items sent in 
compressed lists. The compressor assigns a unique identifier, 
"Index", to each item, "Item", of a list. 


Compressor Logic 


The compressor conceptually maintains an item table containing all 
items, indexed using "Index". The (Index, Item) pair is sent 
together in compressed lists until the compressor gains enough 
confidence that the decompressor has observed the mapping between 
items and their respective index. Confidence is obtained from the 
reception of an acknowledgment from the decompressor, or by 
sending (Index, Item) pairs using the optimistic approach. Once 
confidence is obtained, the index alone is sent in compressed 
lists to indicate the presence of the item corresponding to this 
index. 


The compressor may reassign an existing index to a new item, by 
re-establishing the mapping using the procedure described above. 


Decompressor Logic 


The decompressor conceptually maintains an item table that 
contains all (Index, Item) pairs received. The item table is 
updated whenever an (Index, Item) pair is received and 
decompression is successfully verified using the CRC. The 
decompressor retrieves the item from the table whenever an index 
without an accompanying item is received. 


If an index without an accompanying item is received and the 
decompressor does not have any context for this index, the header 
MUST be discarded and a NACK SHOULD be sent. 


3. Encoding of Compressed Lists 
Each item present in a compressed list is represented by: 
o an index into the table of items 


o a presence bit indicating if a compressed representation of the 
item is present in the list 


o an item (if the presence bit is set) 


Decompression of an item will fail if the presence bit is not set and 
the decompressor has no entry in the context for that item. 
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A compressed list of TCP options uses the following encoding: 


0 d 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 


| Reserved |PS | m | 
+---+---+---+---+---+---+---+---+ 

| XP Sayo LM | m octets, or m * 4 bits 
/ KJE EEE 

| è Padding : if PS = 0 and m is odd 


4+---4---4---4---+4---+---+---+---+ 


/ item 1, ..., item_n / variable 


+---+---+---+---+---+---+---+---+ 


Reserved: MUST be set to zero; otherwise, the decompressor MUST 


discard the packet. 


PS: Indicates size of XI fields: 
PS = 0 indicates 4-bit XI fields; 


PS 1 indicates 8-bit XI fields. 


m: Number of XI item(s) in the compressed list. 


XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in 
the uncompressed packet, in the same order as they appear in the 


uncompressed packet. 
The format of an XI item is as follows: 


+---+---+---+---+ 
PS=0: |x| Index | 
+---+---+---+---+ 


0 1 2 3 4 5 6 7 
tatters += 
PS = 1: | X | Reserved | Index 
+= tt HH 
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X: Indicates whether the item is present in the list: 


X = 1 indicates that the item corresponding to the Index is 
sent in the item 1, ..., item_n list; 
X = 0 indicates that the item corresponding to the Index is 


not sent and is instead included in the irregular chain. 


Reserved: MUST be set to zero; otherwise, the decompressor MUST 
discard the packet. 


Index: An index into the item table. See Section 6.3.4. 


When 4-bit XI items are used, the XI items are placed in octets 
in the following manner: 


Gi OT) GE DW W dE YO oo 
+---+---+---+---+---+---+---+---+ 
| XI_k | XI_k + 1 | 
+---+---+---+---+---+---+---+---+ 


Padding: A 4-bit padding field is present when PS = 0 and the 
number of XIs is odd. The Padding field MUST be set to zero; 
otherwise, the decompressor MUST discard the packet. 


Item 1, ..., item n: Each item corresponds to an XI with X = 1 in 
XI 1, ..., XI m. The format of the entries in the item list is 
described in the table in Section 6.3. The compressed format (s) 
suffixed by "_list_item" in the encoding methods defines the item 
inside the compressed item list. 


6.3.4. Item Table Mappings 
The item table for TCP options list compression is limited to 16 
different items, since it is unlikely that any packet flow will 


contain a larger number of unique options. 


The mapping between the TCP option type and table indexes are listed 
in the table below: 
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+ e ero ere ero ero ero ero ero ere ero ero ero ero ero ern ero e 
| Option name 


ser fo ip aea e ee + 
Table index | 


| 

| EOL 

| MSS 

| WINDOW SCALE 

| TIMESTAMP 
SACK-PERMITTED 

SACK 
| Generic options 
+ HER eye e 


+ ve 
| 
| 
l 
l 
| 
l 
l 
l 
| 
| 
l 
l 
| 
+ 


Some TCP options are used more frequently than others. To simplify 
their compression, a part of the item table is reserved for these 
option types, as shown on the table above. Both the compressor and 
the decompressor MUST use these mappings between item and indexes to 
(de) compress TCP options when using list compression. 


It is expected that the option types for which an index is reserved 
in the item table will only appear once in a list. However, if an 
option type is detected twice in the same options list and if both 
options have a different content, the compressor should compress the 
second occurrence of the option type by mapping it to a generic 
compressed option. Otherwise, if the options have the exact same 
content, the compressor can still use the same table index for both. 


The NOP option 


The NOP option can appear more than once in the list. However, 
since its value is always the same, no context information needs 
to be transmitted. Multiple NOP options can thus be mapped to the 
same index. Since the NOP option does not have any content when 
compressed as a "_list_item", it will never be present in the item 
list. For consistency, the compressor should still establish an 
entry in the list by setting the presence bit, as done for the 
other type of options. 


List compression always preserves the original order of each item 
in the decompressed list, whether or not the item is present in 
the compressed " list item" or if multiple items of the same type 
can be mapped to the same index, as for the NOP option. 
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The EOL option 


The size of the compressed format for the EOL option can be larger 
than one octet, and it is defined so that it includes the option 
padding. This is because the EOL should terminate the parsing of 
the options, but it can also be followed by padding octets that 
all have the value zero. 


The Generic option 


The Generic option can be used to compress any type of TCP option 
that does not have a reserved index in the item table. 


6.3.5. Compressed Lists in Dynamic Chain 


A compressed list for TCP options that is part of the dynamic chain 
(e.g., in IR or IR-DYN packets) must have all its list items present, 
i.e., all X-bits in the XI list MUST be set. 


6.3.6. Irregular Chain Items for TCP Options 


The "_list_item" represents the option inside the compressed item 
list, and the "_irregular" format is used for the option fields that 
are expected to change with each packet. When an item of the 
specified type is present in the current context, these irregular 
fields are present in each compressed packet, as part of the 
irregular chain. Since many of the TCP option types are not expected 
to change for the duration of a flow, many of the "_irregular" 
formats are empty. 


The irregular chain for TCP options is structured analogously to the 
structure of the TCP options in the uncompressed packet. If a 
compressed list is present in the compressed packet, then the 
irregular chain for TCP options must not contain irregular items for 
the list items that are transmitted inside the compressed list (i.e., 
items in the list that have the X-bit set in its XI). The items that 
are not present in the compressed list, but are present in the 
uncompressed list, must have their respective irregular items present 
in the irregular chain. 


6.3.7. Replication of TCP Options 
The entire table of TCP options items is always replicated when using 
the IR-CR packet. In the IR-CR packet, the list of options for the 


new flow is also transmitted as a compressed list in the IR-CR 
packet. 
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6.4. Profile-Specific Encoding Methods 


This section defines encoding methods that are specific to this 
profile. These methods are used in the formal definition of the 
packet formats in Section 8. 


6.4.1. inferred ip v4 header checksum 


This encoding method compresses the Header Checksum field of the IPv4 
header. This checksum is defined in [RFC0791] as follows: 


Header Checksum: 16 bits 


A checksum on the header only. Since some header fields change 
(e.g., time to live), this is recomputed and verified at each 
point that the internet header is processed. 


The checksum algorithm is: 


The checksum field is the 16-bit one’s complement of the one’s 
complement sum of all 16-bit words in the header. For purposes 
of computing the checksum, the value of the checksum field is 
zero. 


As described above, the header checksum protects individual hops from 
processing a corrupted header. When almost all IP header information 
is compressed away, and when decompression is verified by a CRC 
computed over the original header for every compressed packet, there 
is no point in having this additional checksum; instead, it can be 
recomputed at the decompressor side. 


The "inferred_ip_v4_header_checksum" encoding method thus compresses 
the IPv4 header checksum down to a size of zero bits. Using this 
encoding method, the decompressor infers the value of this field 
using the computation above. 


This encoding method implicitly assumes that the compressor will not 
process a corrupted header; otherwise, it cannot guarantee that the 
checksum as recomputed by the decompressor will be bitwise identical 
to its original value before compression. 


6.4.2. inferred_mine_header_checksum 


This encoding method compresses the minimal encapsulation header 
checksum. This checksum is defined in [RFC2004] as follows: 
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Header Checksum 


The 16-bit one’s complement of the one’s complement sum of all 
16-bit words in the minimal forwarding header. For purposes of 
computing the checksum, the value of the checksum field is 


zero. The IP header and IP payload (after the minimal 
forwarding header) are not included in this checksum 
computation. 


The "inferred_mine_header_checksum" encoding method compresses the 
minimal encapsulation header checksum down to a size of zero bits, 
i.e., no bits are transmitted in compressed headers for this field. 
Using this encoding method, the decompressor infers the value of this 
field using the above computation. 


The motivations and the assumptions for inferring this checksum are 
similar to the ones explained above in Section 6.4.1. 


6.4.3. inferred_ip_v4_length 


This encoding method compresses the Total Length field of the IPv4 
header. The Total Length field of the IPv4 header is defined in 
[RECO791] as follows: 


Total Length: 16 bits 


Total Length is the length of the datagram, measured in octets, 
including internet header and data. This field allows the 
length of a datagram to be up to 65,535 octets. 


The "inferred_ip_v4_length" encoding method compresses the IPv4 Total 
Length field down to a size of zero bits. Using this encoding 
method, the decompressor infers the value of this field by counting 
in octets the length of the entire packet after decompression. 


6.4.4. inferred_ip_v6_length 


This encoding method compresses the Payload Length field of the IPv6 
header. This length field is defined in [RFC2460] as follows: 


Payload Length: 16-bit unsigned integer 


Length of the IPv6 payload, i.e., the rest of the packet 
following this IPv6 header, in octets. (Note that any 
extension headers present are considered part of the payload, 
i.e., included in the length count.) 
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The "inferred ip v6 length" encoding method compresses the Payload 
Length field of the IPv6 header down to a size of zero bits. Using 
this encoding method, the decompressor infers the value of this field 
by counting in octets the length of the entire packet after 
decompression. 


6.4.5. inferred offset 


This encoding method compresses the data offset field of the TCP 
header. 


The "inferred offset" encoding method is used on the Data Offset 
field of the TCP header. This field is defined in [RFCO793] as: 


Data Offset: 4 bits 


The number of 32-bit words in the TCP header. This indicates 
where the data begins. The TCP header (even one including 
options) is an integral number of 32 bits long. 


The "inferred offset" encoding method compresses the Data Offset 
field of the TCP header down to a size of zero bits. Using this 
encoding method, the decompressor infers the value of this field by 
first decompressing the TCP options list, and by then setting: 


data offset = (options length / 4) + 5 


The equation above uses integer arithmetic. 
6.4.6. baseheader extension headers 


In CO packets (see Section 7.3), the innermost IP header and the TCP 
header are combined to create a compressed base header. In some 
cases, the IP header will have a number of extension headers between 
itself and the TCP header. 


To remain formally correct, the base header must define some 
representation of these extension headers, which is what this 
encoding method is used for. This encoding method skips over all the 
extension headers and does not encode any of the fields. Changed 
fields in these headers are encoded in the irregular chain. 
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6.4.7. baseheader outer headers 


This encoding method, as well as the baseheader extension headers 
encoding method described above, is needed for the specification to 
remain formally correct. It is used in CO packets (see Section 7.3) 
to describe tunneling IP headers and their respective extension 
headers (i.e., all headers located before the innermost IP header). 


This encoding method skips over all the fields in these headers and 
does not perform any encoding. Changed fields in outer headers are 
instead handled by the irregular chain. 


6.4.8. Scaled Encoding of Fields 


Some header fields will exhibit a change pattern where the field 
increases by a constant value or by multiples of the same value. 


Examples of fields that may have this behavior are the TCP Sequence 
Number and the TCP Acknowledgment Number. For such fields, ROHC-TCP 
provides the means to downscale the field value before applying LSB 
encoding, which allows the compressor to transmit fewer bits. 


To be able to use scaled encoding, the field is required to fulfill 
the following equation: 


unscaled value = scaling factor * scaled value + residue 


To use the scaled encoding, the compressor must be confident that the 
decompressor has established values for the "residue" and the 
"scaling factor", so that it can correctly decompress the field when 
only an LSB-encoded "scaled value" is present in the compressed 
packet. 


Once the compressor is confident that the value of the scaling factor 
and the value of the residue have been established in the 
decompressor, the compressor may send compressed packets using the 
scaled representation of the field. The compressor MUST NOT use 
scaled encoding with the value of the scaling factor set to zero. 


If the compressor detects that the value of the residue has changed, 
or if the compressor uses a different value for the scaling factor, 
it MUST NOT use scaled encoding until it is confident that the 
decompressor has received the new value(s) of these fields. 


When the unscaled value of the field wraps around, the value of the 
residue is likely to change, even if the scaling_factor remains 
constant. In such a case, the compressor must act in the same way as 
for any other change in the residue. 
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The following subsections describe how the scaled encoding is applied 
to specific fields in ROHC-TCP, in particular, how the scaling factor 
and residue values are established for the different fields. 


6.4.8.1. Scaled TCP Sequence Number Encoding 


For some TCP flows, such as data transfers, the payload size will be 
constant over periods of time. For such flows, the TCP Sequence 
Number is bound to increase by multiples of the payload size between 
packets, which means that this field can be a suitable target for 
scaled encoding. When using this encoding, the payload size will be 
used as the scaling factor (i.e., as the value for scaling_factor) of 
this encoding. This means that the scaling factor does not need to 
be explicitly transmitted, but is instead inferred from the length of 
the payload in the compressed packet. 


Establishing scaling_factor: 
The scaling factor is established by sending unscaled TCP Sequence 
Number bits, so that the decompressor can infer the scaling_factor 
from the payload size. 


Establishing residue: 


The residue is established identically as the scaling_factor, 
i.e., by sending unscaled TCP Sequence Number bits. 


A detailed specification of how the TCP Sequence Number uses the 
scaled encoding can be found in the definitions of the packet 
formats, in Section 8.2. 


6.4.8.2. Scaled Acknowledgment Number Encoding 


Similar to the pattern exhibited by the TCP Sequence Number, the 
expected increase in the TCP Acknowledgment Number is often constant 
and is therefore suitable for scaled encoding. 


For the TCP Acknowledgment Number, the scaling factor depends on the 
size of packets flowing in the opposite direction; this information 
might not be available to the compressor/decompressor pair. For this 
reason, ROHC-TCP uses an explicitly transmitted scaling factor to 
compress the TCP Acknowledgment Number. 
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Establishing scaling factor: 


The scaling factor is established by explicitly transmitting the 
value of the scaling factor (called ack stride in the formal 
notation in Section 8.2) to the decompressor, using one of the 
packet types that can carry this information. 


Establishing residue: 


The scaling residue is established by sending unscaled TCP 
Acknowledgment Number bits, so that the decompressor can infer its 
value from the unscaled value and the scaling factor (ack stride). 


A detailed specification of how the TCP Acknowledgment Number uses 
the scaled encoding can be found in the definitions of the packet 
formats, in Section 8.2. 


The compressor MAY use the scaled acknowledgment number encoding; 
what value it will use as the scaling factor is up to the compressor 
implementation. In the case where there is a co-located decompressor 
processing packets of the same TCP flow in the opposite direction, 
the scaling factor for the sequence number used for that flow can be 
used by the compressor to determine a suitable scaling factor for the 
TCP Acknowledgment number for this flow. 


6.5. Encoding Methods with External Parameters 


A number of encoding methods in Section 8.2 have one or more 
arguments for which the derivation of the parameter’s value is 
outside the scope of the ROHC-FN specification of the header formats. 
This section lists the encoding methods together with a definition of 
each of their parameters. 


o ipv6(is innermost, EEL irregular chain flag, ip_inner_ecn): 


is innermost: This Boolean flag is set to true when processing 
the innermost IP header; otherwise, it is set to false. 


ttl irregular chain flag: This parameter must be set to the 
value that was used for the corresponding 

"ttl irregular chain flag" parameter of the "co baseheader" 
encoding method (as defined below) when extracting the 
irregular chain for a compressed header; otherwise, it is set 
to zero and ignored for other types of chains. 


ip_inner_ecn: This parameter is bound by the encoding method; 
therefore, it should be undefined when calling this encoding 
method. This value is then used to bind the corresponding 
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parameter in the "tcp" encoding method, as its value is needed 
when processing the irregular chain for TCP. See the 
definition of the "ip inner ecn" parameter for the "tcp" 
encoding method below. 


o ipv4(is_innermost, ttl irregular chain flag, ip inner ecn, 
ip id behavior value): 


See definition of arguments for "ipv6" above. 
ip id behavior value: Set to a 2-bit integer value, using one 


of the constants whose name begins with the prefix 
IP_ID_BEHAVIOR_ and as defined in Section 8.2. 


o tcp opt eol(nbits): 


nbits: This parameter is set to the length of the padding data 
located after the EOL option type octet to the end of the TCP 
options in the uncompressed header. 


o tcp opt sack(ack value): 


ack value: Set to the value of the Acknowledgment Number field 
of the TCP header. 


o tcp(payload size, ack stride value, ip inner ecn): 


payload size: Set to the length (in octets) of the payload 
following the TCP header. 


ack stride value: This parameter is the scaling factor used 
when scaling the TCP Acknowledgment Number. Its value is set 
by the compressor implementation. See Section 6.4.8.2 for 
recommendations on how to set this value. 


ip_inner_ecn: This parameter binds with the value given to the 
corresponding "ip inner ecn" parameter by the "ipv4" or the 
"ipv6" encoding method when processing the innermost IP header 
of this packet. See also the definition of the "ip_inner_ecn" 
parameter to the "ipv6" and "ipv4" encoding method above. 


o co baseheader(payload size, ack_stride_value, 
ttl irregular chain flag, ip id behavior value): 


payload size: Set to the length (in octets) of the payload 
following the TCP header. 
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ack stride value: This parameter is the scaling factor used 
when scaling the TCP Acknowledgment Number. Its value is set 
by the compressor implementation. See Section 6.4.8.2 for 
recommendations on how to set this value. 


ttl irregular chain flag: This parameter is set to one if the 
TTL/Hop Limit of an outer header has changed compared to its 
reference in the context; otherwise, it is set to zero. The 
value used for this parameter is also used for the 

"ttl irregular chain flag" argument for the "ipv4" and "ipv6" 
encoding methods when processing the irregular chain, as 
defined above for the "ipv6" and "ipv4" encoding methods. 


ip id behavior value: Set to a 2-bit integer value, using one 
of the constants whose name begins with the prefix 
IP_ID_BEHAVIOR_ and as defined in Section 8.2. 
7. Packet Types (Normative) 
ROHC-TCP uses three different packet types: the Initialization and 
Refresh (IR) packet type, the Context Replication (IR-CR) packet 
type, and the Compressed (CO) packet type. 
Each packet type defines a number of packet formats: two packet 
formats are defined for the IR type, one packet format is defined for 
the IR-CR type, and two sets of eight base header formats are defined 
for the CO type with one additional format that is common to both 
sets. 
The profile identifier for ROHC-TCP is 0x0006. 
7.1. Initialization and Refresh (IR) Packets 


ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets 
as defined in [RFC5795] (Sections 5.2.2.1 and 5.2.2.2, respectively). 


Packet type: IR 


This packet type communicates the static part and the dynamic part 
of the context. 


For the ROHC-TCP IR packet, the value of the x bit MUST be set to 


one. It has the following format, which corresponds to the 
"Header" and "Payload" fields described in Section 5.2.1 of 
[RFC5795]: 
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0 1 2 3 4 9 6 7 


a Add-CID octet : if for small CIDs and (CID != 0) 
+---4+---+---4+---+---4+---+---+---+ 

| 1 1 1 1 1 1 0 1 | IR type octet 
+---4+---+---4+---+---4+---+---+---+ 


/ 0-2 octets of CID / 1-2 octets if for large CIDs 


+---+---+---+---+---+---+---+---+ 


| Profile = 0x06 | 1 octet 
roro propo propo poo 
| CRC | 1 octet 


4+---4---4---4---+---+4---+---+---+ 


/ Static chain / variable length 
/ Dynamic chain / variable length 
/ Payload / variable length 


CRC: 8-bit CRC, computed according to Section 5.3.1.1 of 
[RFC5795]. The CRC covers the entire IR header, thus excluding 
payload, padding, and feedback, if any. 
Static chain: See Section 6.2. 
Dynamic chain: See Section 6.2. 
Payload: The payload of the corresponding original packet, if any. 
The payload consists of all data after the last octet of the TCP 
header to the end of the uncompressed packet. The presence of a 
payload is inferred from the packet length. 

Packet type: IR-DYN 
This packet type communicates the dynamic part of the context. 
The ROHC-TCP IR-DYN packet has the following format, which 


corresponds to the "Header" and "Payload" fields described in 
Section 5.2.1 of [RFC5795]: 
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0 1 2 3 4 J 6 7 


å Add-CID octet : if for small CIDs and (CID != 0) 
+---+---+---+---+---+---+---+---+ 

| 1 1 1 1 1 0 0 0 | IR-DYN type octet 
+---+---+---+---+---+---+---+---+ 


/ 0-2 octets of CID / 1-2 octets if for large CIDs 


+---+---+---+---+---+---+---+---+ 


| Profile = 0x06 | 1 octet 
roro propo propo poo 
| CRC | 1 octet 


Ha a a A A A 


/ Dynamic chain / variable length 


d Payload / variable length 


CRC: 8-bit CRC, computed according to Section 5.3.1.1 of 
[RFC5795]. The CRC covers the entire IR-DYN header, thus 
excluding payload, padding, and feedback, if any. 


Dynamic chain: See Section 6.2. 


Payload: The payload of the corresponding original packet, if any. 
The payload consists of all data after the last octet of the TCP 
header to end of the uncompressed packet. The presence of a 
payload is inferred from the packet length. 


7.2. Context Replication (IR-CR) Packets 
Context replication requires a dedicated IR packet format that 
uniquely identifies the IR-CR packet for the ROHC-TCP profile. This 
section defines the profile-specific part of the IR-CR packet 
[RFC4164]. 
Packet type: IR-CR 
This packet type communicates a reference to a base context along 


with the static and dynamic parts of the replicated context that 
differs from the base context. 
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The ROHC-TCP IR-CR packet follows the general format of the ROHC 
IR-CR packet, as defined in [RFC4164], Section 3.5.2. With 
consideration to the extensibility of the IR packet type defined in 
[RFC5795], the ROHC-TCP profile supports context replication through 
the profile-specific part of the IR packet. This is achieved using 
the bit (x) left in the IR header for "Profile specific information". 
For ROHC-TCP, this bit is defined as a flag indicating whether this 
packet is an IR packet or an IR-CR packet. For the ROHC-TCP IR-CR 
packet, the value of the x bit MUST be set to zero. 


The ROHC-TCP IR-CR has the following format, which corresponds to the 
"Header" and "Payload" fields described in Section 5.2.1 of 
[RFC5795]: 


0 1 2 3 4 5 6 7 


: Add-CID octet : if for small CIDs and (CID != 0) 
+---+---+---+---+---+---+---+---+ 

Kt 1 1 1 1 1 0 0 | IR-CR type octet 
+---+---+---+---+---+---+---+---+ 


/ 0-2 octets of CID / 1-2 octets if for large CIDs 


Ha a a A a A A 


| Profile = 0x06 | 1 octet 
+---+---+---+---+---+---+---+---+ 
| CRC | 1 octet 
+—---+---+---+---+---+---+---+---+ 
| B | CRC7 | 1 octet 
4+---4+---4---+---4---+---4---+---+ 

Reserved | Base CID : 1 octet, for small CID, if B=1 


+---+---+---+---+---+---+---+---+ 


/ Base CID / 1-2 octets, for large CIDs, 
: : if B=1 
+—---+---+---+---+---+---+---+---+ 


/ Replicate chain / variable length 


/ Payload / variable length 
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B: B = 1 indicates that the Base CID field is present. 

CRC: This CRC covers the entire IR-CR header, thus excluding 
payload, padding, and feedback, if any. This 8-bit CRC is 
calculated according to Section 5.3.1.1 of [RFC5795]. 


CRC7: The CRC over the original, uncompressed, header. Calculated 
according to Section 3.5.1.1 of [RFC4164]. 


Reserved: MUST be set to zero; otherwise, the decompressor MUST 
discard the packet. 


Base CID: CID of base context. Encoded according to [RFC4164], 
Section aedo 


Replicate chain: See Section 6.2. 


Payload: The payload of the corresponding original packet, if any. 
The presence of a payload is inferred from the packet length. 


7.3. Compressed (CO) Packets 


The ROHC-TCP CO packets communicate irregularities in the packet 
header. All CO packets carry a CRC and can update the context. 


The general format for a compressed TCP header is as follows, which 
corresponds to the "Header" and "Payload" fields described in Section 
Ga de GE [RECI TIS] 
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0 1 2 3 4 3 6 7 


: Add-CID octet : if for small CIDs and CID 1-15 
+---+---+---+---+---+---+---+---+ 
| First octet of base header | (with type indication) 


+---+---+---+---+---+---+---+---+ 
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 


Fr rp pepe pr pro 
/ Remainder of base header / variable number of octets 
4+---4+---4+---4+---4---4+---+---+---+ 
: Irregular chain : 
/ (including irregular chain / variable 
items for TCP options) 


/ Payload / variable length 


Base header: The complete set of base headers is defined in 
Section 8. 


Irregular chain: See Sections 6.2 and 6.3.6. 


Payload: The payload of the corresponding original packet, if any. 
The presence of a payload is inferred from the packet length. 


8. Header Formats (Normative) 


This section describes the set of compressed TCP/IP packet formats. 
The normative description of the packet formats is given using the 
formal notation for ROHC profiles defined in [RFC4997]. The formal 
description of the packet formats specifies all of the information 
needed to compress and decompress a header relative to the context. 


In particular, the notation provides a list of all the fields present 
in the uncompressed and compressed TCP/IP headers, and defines how to 
map from each uncompressed packet to its compressed equivalent and 
vice versa. 
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8.1. Design Rationale for Compressed Base Headers 


The compressed header formats are defined as two separate sets: one 
set for the packets where the innermost IP header contains a 
sequential IP-ID (either network byte order or byte swapped), and one 
set for the packets without sequential IP-ID (either random, zero, or 
no IP-ID). 


These two sets of header formats are referred to as the "sequential" 
and the "random" set of header formats, respectively. 


In addition, there is one compressed format that is common to both 
sets of header formats and that can thus be used regardless of the 
type of IP-ID behavior. This format can transmit rarely changing 
fields and also send the frequently changing fields coded in variable 
lengths. It can also change the value of control fields such as 
IP-ID behavior and ECN behavior. 


All compressed base headers contain a 3-bit CRC, unless they update 
control fields such as "ip id behavior" or "ecn used" that affect the 
interpretation of subsequent headers. Headers that can modify these 
control fields carry a 7-bit CRC instead. 


When discussing LSB-encoded fields below, "p" equals the 
"offset param" and "k" equals the "num_lsbs_param" in [RFC4997]. 


The encoding methods used in the compressed base headers are based on 
the following design criteria: 


o MSN 


Since the MSN is a number generated by the compressor, it only 
needs to be large enough to ensure robust operation and to 
accommodate a small amount of reordering [RFC4163]. Therefore, 
each compressed base header has an MSN field that is LSB- 
encoded with k=4 and p=4 to handle a reordering depth of up to 
4 packets. Additional guidance to improve robustness when 
reordering is possible can be found in [RFC4224]. 


o TCP Sequence Number 


ROHC-TCP has the capability to handle bulk data transfers 
efficiently, for which the sequence number is expected to 
increase by about 1460 octets (which can be represented by 11 
bits). For the compressed base headers to handle 
retransmissions (i.e., negative delta to the sequence number), 
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the LSB interpretation interval has to handle negative offsets 
about as large as positive offsets, which means that one more 
bit is needed. 


Also, for ROHC-TCP to be robust to losses, two additional bits 
are added to the LSB encoding of the sequence number. This 
means that the base headers should contain at least 14 bits of 
LSB-encoded sequence number when present. According to the 
logic above, the LSB offset value is set to be as large as the 
positive offset, i.e., p = 2” (k-1)-1. 


o TCP Acknowledgment Number 


The design criterion for the acknowledgment number is similar 
to that of the TCP Sequence Number. However, often only every 
other data packet is acknowledged, which means that the 
expected delta value is twice as large as for sequence numbers. 


Therefore, at least 15 bits of acknowledgment number should be 
used in compressed base headers. Since the acknowledgment 
number is expected to constantly increase, and the only 
exception to this is packet reordering (either on the ROHC 
channel [RFC3759] or prior to the compression point), the 
negative offset for LSB encoding is set to be 1/4 of the total 
interval, i.e., p = 2%(k-2)-1. 


o TCP Window 


The TCP Window field is expected to increase in increments of 
similar size as the TCP Sequence Number; therefore, the design 
criterion for the TCP window is to send at least 14 bits when 
used. 


o IP-ID 


For the "sequential" set of packet formats, all the compressed 
base headers contain LSB-encoded IP-ID offset bits, where the 
offset is the difference between the value of the MSN field and 
the value of the IP-ID field. The requirement is that at least 
3 bits of IP-ID should always be present, but it is preferable 
to use 4 to 7 bits. When k=3 then p=1, and if k>3 then p=3 
since the offset is expected to increase most of the time. 


Each set of header formats contains eight different compressed base 
headers. The reason for having this large number of header formats 
is that the TCP Sequence Number, TCP Acknowledgment Number, and TCP 
Window are frequently changing in a non-linear pattern. 
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The design of the header formats is derived from the field behavior 
analysis found in [RFC4413]. 


All of the compressed base headers transmit LSB-encoded MSN bits, the 
TCP Push flag, and a CRC, and in addition to this, all the base 
headers in the sequential packet format set contain LSB-encoded IP-ID 
bits. 


The following header formats exist in both the sequential and random 
packet format sets: 


o 


Format 1: This header format carries changes to the TCP Sequence 
Number and is expected to be used on the downstream of a data 
transfer. 


Format 2: This header format carries the TCP Sequence Number in 
scaled form and is expected to be useful for the downstream of a 
data transfer where the payload size is constant for multiple 
packets. 


Format 3: This header format carries changes in the TCP 
Acknowledgment Number and is expected to be useful for the 
acknowledgment direction of a data transfer. 


Format 4: This header format is similar to format 3, but carries a 
scaled TCP Acknowledgment Number. 


Format 5: This header format carries both the TCP Sequence Number 
and the TCP Acknowledgment Number and is expected to be useful for 
flows that send data in both directions. 


Format 6: This header format is similar to format 5, but carries 
the TCP Sequence Number in scaled form, when the payload size is 
static for certain intervals in a data flow. 


Format 7: This header format carries changes to both the TCP 
Acknowledgment Number and the TCP Window and is expected to be 
useful for the acknowledgment flows of data connections. 


Format 8: This header format is used to convey changes to some of 
the more seldom changing fields in the TCP flow, such as ECN 
behavior, RST/SYN/FIN flags, the TTL/Hop Limit, and the TCP 
options list. This format carries a 7-bit CRC, since it can 
change the structure of the contents of the irregular chain for 
subsequent packets. Note that this can be seen as a reduced form 
of the common packet format. 
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o Common header format: The common header format can be used for all 
kinds of IP-ID behavior and should be useful when some of the more 


rarely changing fields in the IP or TCP header change. 


Since this 


header format can update control fields that decide how the 


decompressor interprets packets, 


the probability of context corruption. 
convey Changes to any of the dynamic fields in the IP and TCP 
headers, and it uses a large set of flags to provide information 


about which fields are present in the header format. 


8.2. Formal Definition of Header Formats 


// NOTE: The irregular, static, 


// methods. In particular, note that the static and dynamic 
// chains ordinarily go together. 
// defined across these two formats combined, 


AAA TITT TT TITT TT TT TLL TET LTL TLL LTL TLL LTL 


// Constants 


LITT AAA AAA AAA AAA AAA AAA AAA AAA AAA 


IP_ID_BEHAVIOR_SEQUENTIAL = 0; 
IP ID BEHAVIOR SEQUENTIAL SWAPPED = 1; 


IP ID BEHAVIOR RANDOM = 2; 
IP ID BEHAVIOR ZERO = 3; 


HIT TT TITT TT TITT ATTA ATTA ATA YOU UD DL LILI 


// Global control fields 


AAA AAA AAA AAA AAA TT LTTE ATTA AAA OU UD TTT TTT 


CONTROL { 
ecn_used KO 
msn [ 16 ]; 


// ip id fields are for innermost IP header only 


ip id offset 

ip id behavior innermost 
// ACK-related 

ack stride 

ack number scaled 

ack number residue 

seq number scaled 

seq number residue 
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Aa om po 


it carries a 7-bit CRC to reduce 


This header can basically 


and dynamic chains 


(see Section 6.2) 
// are defined across multiple encoding methods and are embodied 
// in the correspondingly named formats within those encoding 


The uncompressed fields are 


rather than in one 
// or the other of them. The irregular chain items are likewise 
// combined with a baseheader format. 


16 
2 


32 
32 
32 
32 
32 


bea bea 


bea bea beai bea bea 


se 


se 


se se see 


se 
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AAA AAA TLL TILT LTL TT LTL TLL TT TLL TT 
// Encoding methods not specified in FN syntax 
ARA AAA LTL ATTA TT LTL LTL TT LTL TLL TT FLL TT 


list tcp options "defined in Section 6.3.3"; 
inferred ip v4 header checksum "defined in Section 6.4.1"; 
inferred mine header checksum "defined in Section 6.4.2"; 
inferred ip v4 length "defined in Section 6.4.3"; 
inferred ip v6 length "defined in Section 6.4.4"; 
inferred offset "defined in Section 6.4.5"; 
baseheader extension headers "defined in Section 6.4.6"; 
baseheader outer headers "defined in Section 6.4.7"; 


AAA AAA AAA AAA AAA YO OO OO OUE AAA AAT AAT 
// General encoding methods 


HA TTT TTT TATA TTT TTT TTT LI 


static_or_irreg(flag, width) 
{ 
UNCOMPRESSED { 
field [ width ]; 
} 


COMPRESSED irreg_enc { 
field =:= irregular(width) [ width ]; 
ENFORCE (flag == ); 

} 


COMPRESSED static_enc { 
field =:= static [ 0 ]; 
ENFORCE (flag == ); 

} 

} 


zero_or_irreg(flag, width) 
{ 
UNCOMPRESSED { 
field [ width ]; 
} 


COMPRESSED non_zero { 
field =:= irregular(width) [ width ]; 
ENFORCE (flag == 0); 

} 


COMPRESSED zero { 


field =:= uncompressed_value(width, 0) [ 0 ]; 
ENFORCE (flag == )i 
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} 


variable length 32 enc(flag) 
{ 
UNCOMPRESSED ( 
field [ 32 ]; 
} 


COMPRESSED not_present { 
field =:= static [ 0 ]; 
ENFORCE (flag == 0); 

} 


COMPRESSED lsb 8 bit { 
field =:= lsb(8, 63) [ 8 ]; 
ENFORCE (flag == UK 

} 


COMPRESSED lsb_16_bit { 
field =:= 1lsb(16, 16383) [ 16 1; 
ENFORCE (flag == 2); 

} 


COMPRESSED irreg 32 bit { 
field =:= irregular(32) [ 32 ]; 
ENFORCE (flag == ); 
) 
) 


optional32 (flag) 
{ 
UNCOMPRESSED ( 
item [ 0, 32 ]; 
} 


COMPRESSED present { 
item =:= irregular(32) [ 32 ]; 
ENFORCE (flag == ); 

) 


COMPRESSED not present { 
item =:= compressed value(0, 0) [ 0 ]; 
ENFORCE (flag == 0); 
) 
) 


Sb. 7 or 31 
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UNCOMPRESSED ( 
item [ 32 ]; 
) 


COMPRESSED lsb 7 { 
discriminator =:= "0" [ 1 
item =:= lsb(7, 8) [ 7 
} 


COMPRESSED lsb 31 
discriminator =:= "1" Ek JG 
item =:= lsb(31, 256) [ 31 1; 


a 


) 


opt lsb 7 or 31(flag) 
{ 
UNCOMPRESSED { 
item [ 0, 32 ]; 
} 


COMPRESSED present { 
item =:= lsb 7 or 31 [ 8, 32 ]; 
ENFORCE (flag == 1); 

} 


COMPRESSED not_present { 
item =:= compressed value(0, 0) [ 0 ]; 
ENFORCE (flag == 0); 
} 
} 


crc3 (data value, data length) 


{ 
UNCOMPRESSED ( 


} 


COMPRESSED { 
crc value =:= 
crc(3, 0x06, 0x07, data value, data length) [ 3 1; 


) 


crc7 (data value, data length) 


{ 
UNCOMPRESSED { 


} 
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COMPRESSED ( 
crc value =:= 
crc(7, 0x79, Ox7f, data value, data length) [ 7 1; 


} 


one_bit_choice 
{ 
UNCOMPRESSED { 
field [ dy di 
} 


COMPRESSED zero { 

field [ 1 17 

ENFORCE (field.UVALUE == 0); 
} 


COMPRESSED nonzero { 
field [-1 l; 
ENFORCE (field.UVALUE == 1); 


// Encoding method for updating a scaled field and its associated 
// control fields. Should be used both when the value is scaled 
// or unscaled in a compressed format. 
// Does not have an uncompressed side. 
field_scaling(stride_value, scaled_value, unscaled_value, residue_value) 
{ 

UNCOMPRESSED { 

// Nothing 
} 


COMPRESSED no_scaling { 
ENFORCE (stride value == 0); 
ENFORCE (residue value == unscaled value); 
ENFORCE (scaled value == 0); 


COMPRESSED scaling used { 
ENFORCE (stride value != 0); 
ENFORCE (residue value == (unscaled value % stride value)); 
ENFORCE (unscaled value == 
scaled value * stride value + residue value); 
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AAA AAA AAA AAA AAA AA AAA AAA AAA AAA ATT 
// IPv6 Destination options header 


AAA 


ip_dest_opt 
{ 
UNCOMPRESSED { 
next_header [ 8 ]; 


length 18: 16 

value [ length.UVALUE * 64 + 48 ]; 
} 
DEFAULT ( 

length =:= static; 

next_header =:= static; 

value =:= static; 


} 


COMPRESSED dest_opt_static { 
next header =:= irregular (8) 
length := irregular (8) 

} 


[ 8 1; 
[ 8 1; 


COMPRESSED dest opt dynamic ( 
value =:= 


January 2013 


irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; 


} 

COMPRESSED dest opt 0 replicate { 
discriminator =:= "00000000" [ 8 ]; 

) 


COMPRESSED dest opt 1 replicate { 
discriminator =:= “10000000” 
length := irregular (8) 
value := 


[ 8 ]; 
[ 8 ]; 


irregular (engen: UVALUE*64+48) [ length.UVALUE * 64 + 48 1; 


} 


COMPRESSED dest_opt_irregular { 
} 
} 


LILI ITIL TITT AAA AA OO ATTA TT 
// IPv6 Hop-by-Hop options header 
LELLI AAA AAA AA AAA LILITA CLIL IALL 


ip_hop_opt 
{ 
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UNCOMPRESSED { 


next_header [ 8 ]; 

length [085 Jå 

value [ length.UVALUE * 64 + 48 ]; 
} 
DEFAULT { 

length =:= static; 

next_header =:= static; 

value =:= static; 


} 


COMPRESSED hop_opt_static { 


January 2013 


next_header =:= irregular(8) [ 8 ]; 
length =:= irregular(8) [ 8 ]; 
} 
COMPRESSED hop_opt_dynamic { 
value =:= 
irregular (length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 
} 
COMPRESSED hop opt 0 replicate { 
discriminator =:= "00000000" [ 8 ]; 
) 
COMPRESSED hop opt 1 replicate { 
discriminator =:= "10000000" [ 8 1; 
length =:= irregular(8) [ 8 ]; 
value =;= 
irregular (length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 


} 


COMPRESSED hop_opt_irregular { 
} 
} 


JARA 
// IPv6 Routing header 
ARA TLL TILT TLL ITAA IAAT ATT 


ip rout opt 
{ 


UNCOMPRESSED { 
next_header [ 8 ]; 
length L8 J3 
value [ length.UVALUE * 64 + 48 ]; 
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DEFAULT ( 
length =:= static; 
next header =:= static; 
value =;= static; 


} 


COMPRESSED rout_opt_static { 
next header =:= irregular (8) [80 Me 
length =:= irregular(8) [ 8 1; 
value == 
irregular (length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 


} 


COMPRESSED rout_opt_dynamic { 
} 


COMPRESSED rout opt 0 replicate { 
discriminator =:= "00000000" [ 8 ]; 
) 


COMPRESSED rout opt 0 replicate { 


discriminator =:= "10000000" bizka 
length =:= irregular (8) [ 8 1; 
value Seas 


irregular (length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 
} 
COMPRESSED rout_opt_irregular { 
} 
} 


VA NN 
// GRE Header 
VA AAA AAA AAA AA AA AAA AAA AAA AAA 


optional_checksum(flag_value) 
{ 
UNCOMPRESSED { 
value [ 0, 16 ]; 
reservedl [ 0 ; 


} 


COMPRESSED cs_present { 


value =:= irregular (16) [ 16 ]; 
reservedl =:= uncompressed value(16, 0) [ 0 17 
ENFORCE (flag value == 1); 


} 


COMPRESSED not_present { 
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value =:= compressed value(0, 0) [ 0 ]; 
reservedl =:= compressed value(0, 0) [ 0 ]; 
ee value == 0); 
) 
) 
gre proto 
{ 
UNCOMPRESSED { 
protocol [ 16 ]; 
} 
COMPRESSED ether_v4 { 
discriminator =:= compressed_value(1, 0) E 15 
protocol =:= uncompressed_value(16, 0x0800) [ 0 l; 
} 
COMPRESSED ether v6 { 
discriminator =:= compressed_value(1, 1) [rd Tes 
protocol =:= uncompressed_value(16, 0x86DD) [ 0 l; 
} 
} 
gre 
{ 
UNCOMPRESSED { 
c_flag [Eds 
r_flag =:= uncompressed_value (1, 0) [ 1 1; 
k_flag [ 1 ]; 
s_flag ak ise 
reserved0 =:= uncompressed value(9, 0) [ 9 ]; 
version =:= uncompressed_value(3, 0) [ 3 17 
protocol [ 16 ]; 
checksum and res [ 0, 32 1; 
key [407-322 14 
sequence_number PAd SA 


} 


DEFAULT { 
c_flag =:= static; 
k_flag =:= static; 
s_flag =:= static; 
protocol =:= static; 
key =:= static; 
sequence number =:= static; 


} 


COMPRESSED gre_static { 
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ENFORCE ( flag.UVALUE == 1 && checksum_and_res.ULENGTH == 32) 
checksum_and_res.ULENGTH == 0); 


CH 
ENFORCE ((s_flag.UVALUE == 1 66 sequence number.ULENGTH == 32) 


| 
( 
| sequence_number.ULENGTH == E 
protocol := gre_proto 
cuflag =: irregular ( 
k_flag irregular ( 
s_flag =:= irregular (1) 

padding compressed_value(4, 0) 


key =:= optional32 (k_flag.UVALUE) 


1) 
1) 


) 

[ 1 
fød 
[ 1 
[uct 
[ 4 
[ 0 


} 


COMPRESSED gre_dynamic { 
checksum_and_res =:= 
optional checksum(c flag.UVALUE) ; 
sequence_number =:= optional32(s_flag.UVALUE) ; 


, 32 1; 


[ 0, 16 1; 
[ 0 
} 


COMPRESSED gre 0 replicate { 
discriminator =;= "00000000" [ 8 ]; 
checksum and res =:= 
optional checksum(c flag.UVALUE) [ 0, 16 ]; 
sequence number =:= 
optional32 (s_flag.UVALUE) [ 0,8, 032014 


} 


COMPRESSED gre 1 replicate { 

discriminator =;= "10000" 
c flag =:= irregular(l) 
k flag =:= irregular(l) 
s flag =:= irregular(l) 
checksum and res =:= 

optional checksum(c flag.UVALUE) [ 0, 16 1; 
key =:= optional32(k_flag.UVALUE) [ 0, 32 ]; 
sequence number =:= optional32(s_flag.UVALUE) [ 0, 32 1; 


al 


} 


COMPRESSED gre_irregular { 
checksum_and_res =:= 
optional checksum(c flag.UVALUE) [ 0, 16 ]; 
sequence number =:= 
opt lsb 7 or 31(s flag.UVALUE) [ 00. Sin S214 


} 
VL AAAA AAAA IAA AVAAMA AA LAAMA TTT TTT TTT TTT 


// MINE header 
LAA ALARE 
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{ 
UNCOMPRESSED { 
next_header [ 8 ]; 
s_bit ge b 
res_bits E ZZ da 
checksum [ 16 1; 
orig dest k 32 de 
orig src EO, 32 lg 
) 
DEFAULT ( 
next header =:= static; 
s bit =;= static; 
res bits =;= static; 
checksum =:= inferred mine header checksum; 
orig dest =;= static; 
orig src =;= static; 


} 


COMPRESSED mine_static { 
next header =:= irregular (8) 


s_bit = i= 


res_bits =;= 
orig dest 
orig src =: 


} 


irregular (1) 


irregular (7) 


[ 
[ 
// Reserved bits are included to achieve by 
[ 
= irregular (32) [ 
[ 


optional32(s bit.UVALUE) 


COMPRESSED mine dynamic { 


) 


COMPRESSED mine 0 replicate ( 


discriminator =: 


) 


‘00000000’ [ 8 1; 


COMPRESSED mine 1 replicate | 


discriminator =: 
s bit =: 
res_bits =; 
orig_dest =; 
orig_src =: 


} 


“10000000” 

irregular (1) 
irregular (7) 

irregular (32) 
optional32(s bit.UVALUE) 


COMPRESSED mine irregular { 


) 
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AAA AAA TT TT TT TITTET LTL TT AAA TATA ATT TTT 


// 


AAA AAA AAA AA AAA AAA AAA AAA TTT TTT TTT TTT TTT 


ah 
{ 


Pe 
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Authentication Header (AH) 


UNCOMPRESSED ( 


next_header KGko 
length [ 8 ]; 
res_bits [ 16 ]; 
spi [ 32 1; 
sequence_number [ 32 ]; 
icv [ length.UVALUE* 32-32 
} 
DEFAULT ( 
next_header =:= static; 
length =:= static; 
res_bits =:= static; 
spi =:= static; 
sequence_number =:= static; 


} 


COMPRESSED ah_static { 


li 


next header =:= irregular(8) [ 8 1; 
length =:= irregular (8) L 8 ]; 
spi =:= irregular (32) [ 32 1; 
} 
COMPRESSED ah_dynamic { 
res_bits =:= irregular ILS) [ 16 1; 


sequence_number =: irregular(32) [ 


icv 
} 


COMPRESSED ah 0 replicate { 


discriminator =:= "00000000" [ 8 
sequence number =:= irregular(32) [ 32 
icv =;= 


li 


1; 
1; 
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irregular (length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 


irregular (length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 


} 


COMPRESSED ah 1 replicate { 


discriminator =;= "10000000" [ 8 
length =:= irregular(8) [ 8 
res bits =;= irregular(16) [ 16 
spi =;= irregular(32) [ 32 
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} 


sequence_number =:= irregular(32) [ 32 ]; 
icv = i= 
irregular (length. UVALUE* 32-32) [ length.UVALUE*32-32 ]; 


COMPRESSED ah_irregular { 


} 


sequence number =:= lsb 7 or 31 E 8, 32 14% 
icv =;= 
irregular (length.UVALUE*32-32) [ length.UVALUE*32-32 1; 


JA AA T TT 
// IPv6 Header 
JA TLL LL TLL 11111 


fl enc 


{ 


UNCOMPRESSED { 


} 


} 


flow_label [ 20 ]; 


COMPRESSED fl_zero { 


} 


discriminator =:= "0" [ 1 1; 
flow_label = uncompressed_value(20, 0) [ 0 ]; 
reserved =:= "0000" [ 4 ]; 


COMPRESSED fl_non_zero { 


discriminator =:= "1" er shee 
flow_label =:= irregular(20) [ 20 ]; 


// The is_innermost flag is true if this is the innermost IP header 
// If extracting the irregular chain for a compressed packet: 


// 
// 
// 
// 
// 


- ttl irregular chain flag must have the same value as it had when 
processing co baseheader. 

- ip inner ecn is bound in this encoding method and the value that 
it gets bound to should be passed to the tcp encoding method 

For other formats than the irregular chain, these two are ignored 


ipv6 (is innermost, EEL irregular chain flag, ip inner ecn) 


{ 


UNCOMPRESSED { 


version =:= uncompressed_value(4, 6) [ 
dscp [ 
ip_ecn_flags [ 
flow label [ 
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payload_length [ 16 ]; 
next_header [ 81; 
ttl hopl [ 8 1; 
src_addr [ 128 ]; 
dst_addr [ 128 ]; 
} 
DEFAULT ( 
dscp =:= static; 
ip_ecn_flags =:= static; 
flow_label =:= static; 
payload_length =:= inferred_ip_v6_length; 
next_header =:= static; 
ttl hopl =;= static; 
src_addr =:= static; 
dst_addr =:= static; 
) 
COMPRESSED ipv6_static ( 
version flag =:= "1" frank: Zir 
reserved =;= "00" KG Te 
flow_label =:= fl_enc E 5, 20 diz 
next header =:= irregular (8) [ 8 ]; 
src_addr =:= irregular(128) [ 128 ]; 
dst_addr =:= irregular(128) [ 128 ]; 
} 
COMPRESSED ipv6 dynamic { 
dscp =:= irregular(6) [ 6 ]; 
ip_ecn_flags =:= irregular(2) [ 2 ]; 
ttl_hopl =:= irregular(8) [ 8 ]; 
} 
COMPRESSED ipv6_replicate { 
dscp =:= irregular(6) [ 6 17 
ip_ecn_flags =:= irregular(2) [ 2 ]; 
reserved =;= '000’ koi 
flow label =;= fl enc [ 5, 21 13 
) 
COMPRESSED ipv6 outer without ttl irregular { 
dscp =:= static or irreg(ecn used.UVALUE, 6) 


ip ecn flags =:= 


ENFORCE (ttl irregular chain flag 


static or irreg(ecn used.UVALUE, 2) 


ENFORCE (is innermost == false); 


} 


)i 


COMPRESSED ipv6 outer with ttl irregular { 
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dscp =;= static or irreg(ecn used.UVALUE, 6) [ 0, 6 17 
ip ecn flags =:= static or irreg(ecn used.UVALUE, 2) [ 0, 2 17 
ttl hopl =:= irregular(8) ES; los 
ENFORCE (tt1_ Getze chain_flag == 1); 
ENFORCE (is innermost == false); 
) 
COMPRESSED ipv6 innermost irregular { 
ENFORCE (ip inner ecn == ip ecn flags.UVALUE); 
ENFORCE (is innermost == true); 
) 
) 
VANSE NANA NANA NANA NANA NAN AAA AAA AAA AA AAA AAA 
// IPv4 Header 
VANSE NANA N ANANA NANNAN AN AAA STATS TTT TTT 
ip id enc dyn(behavior) 
{ 
UNCOMPRESSED { 
ipotd 1-16 diz 
} 
COMPRESSED ip_id_seq { 
ENFORCE ( (behavior == IP ID BEHAVIOR SEQUENTIAL) | | 
(behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 
ENFORCE (ip id offset.UVALUE == ip id.UVALUE - msn.UVALUE); 
ip id =:= irregular(16) [ 16 ]; 


} 


COMPRESSED ip_id_random { 
ENFORCE (behavior == IP ID BEHAVIOR RANDOM); 
ip id =:= irregular(16) [ 16 ]; 

) 


COMPRESSED ip id zero ( 
ENFORCE (behavior == IP ID BEHAVIOR ZERO); 
ip id =:= uncompressed value(16, 0) [ 0 1; 
) 
) 


ip_id_enc_irreg (behavior) 
{ 
UNCOMPRESSED { 
peta 6: li 
} 


COMPRESSED ip_id_seq { 
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} 


// 
// 
// 
// 
// 
// 
// 


ENFORCE (behavior == IP ID BEHAVIOR SEQUENTIAL); 
) 


COMPRESSED ip id seq swapped ( 
ENFORCE (behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED); 
) 


COMPRESSED ip id rand ( 

ip id =:= irregular(16) [ 16 ]; 

ENFORCE (behavior == IP ID BEHAVIOR RANDOM); 
) 


COMPRESSED ip id zero ( 
ip id =:= uncompressed value(16, 0) [ 0 1; 
ENFORCE (behavior == IP ID BEHAVIOR ZERO); 


The is innermost flag is true if this is the innermost IP header 
If extracting the irregular chain for a compressed packet: 


- ttl irregular chain flag must have the same value as it had when 


processing co baseheader. 


- ip inner ecn is bound in this encoding method and the value that 


it gets bound to should be passed to the tcp encoding method 


For other formats than the irregular chain, these two are ignored 


ipv4(is innermost, ttl irregular chain flag, ip inner ecn, 


{ 


Pe 


ip_id_behavior_value) 


UNCOMPRESSED { 


version =:= uncompressed_value(4, 4) [ 4 ]; 
hdr_length =:= uncompressed_value (4, 5) [ 4 1; 
dscp [ 6 1; 
ip_ecn_flags [2.1% 
length =:= inferred_ip_v4_length [ 16 ]; 
ip id [ 16 ]; 
rf =:= uncompressed_value(1, 0) ET Ii 
df E 
mf =:= uncompressed_value(1, 0) EL TI 
frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 
ttl hopl [ 8 1; 
protocol [ 8 ]; 
checksum =:= inferred ip v4 header checksum [ 16 1; 
src_addr [ 32 ]; 
dst_addr [ 32 1; 

} 

CONTROL { 
ENFORCE (reorder_ratio.UVALUE == reorder ratio value); 
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ENFORCE (innermost_ip.UVALUE == is_innermost) ; 
ip_id_behavior_outer [ 2 ]; 
innermost_ip [ 1 ]; 

} 

DEFAULT { 
dscp =:= static; 
ip_ecn_flags =:= static; 
df =:= static; 
tt1_hopl =:= static; 
protocol =:= static; 
src_addr =:= static; 
dst_addr =:= static; 
ip_id_behavior_outer =:= static; 


} 


COMPRESSED ipv4_static { 


version flag =:= "0" E 1 på 
reserved =:= '0000000’ kò iy 
protocol =:= irregular (8) kal 
src addr =:= irregular(32) [ 32 1; 
dst_addr =:= irregular(32) [ 32 ]; 


} 


COMPRESSED ipv4_innermost_dynamic { 
ENFORCE (is innermost == 1); 
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ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value); 
reserved =:= "00000" Liar OG 
df =:= irregular (1) Eki 
ip id behavior innermost =:= irregular (2) [ 2 ]; 
dscp =:= irregular (6) [ 61; 
ip_ecn_flags =:= irregular (2) Ed hy 
ttl_hopl =:= irregular (8) [ 8 ]; 
ip_id =;= 
ip id enc dyn(ip id behavior innermost.UVALUE) [ 0, 16 l; 
) 
COMPRESSED ipv4 outer dynamic { 
ENFORCE (is innermost == 0); 
ENFORCE (ip id behavior outer.UVALUE == ip id behavior value); 
reserved =:= "00000" svi? 
df =:= irregular(l) ET; 
ip_id_behavior_outer =:= irregular (2) EZ 
dscp =:= irregular(6) [ 61; 
ip_ecn_flags =:= irregular (2) [ 2 15 
ttl_hopl =:= irregular (8) Peta rdo 
ip_id =;= 


ip id enc dyn(ip id behavior outer.UVALUE) 
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} 


COMPRESSED ipv4 innermost replicate | 
ENFORCE (is innermost == 1); 


ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value); 
reserved =;= '0000’ EZ ke 
ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 
ttl_flag =:= irregular (1) Lek E 
df =:= irregular (1) See 
dscp =:= irregular(6) bs Hz 
ip ecn flags =:= irregular(2) [2 14 
ip id =;= 
ip id enc dyn(ip id behavior innermost.UVALUE) [ 0, 16 ]; 

ttl hopl =;= 

static or irreg(ttl flag.UVALUE, 8) [ 0, 8 1; 


} 


COMPRESSED ipv4_outer_replicate | 
ENFORCE (is_innermost == 0); 


ENFORCE (ip id behavior outer.UVALUE == ip id behavior value); 
reserved =;= "0000" kan kz 
ip id behavior outer =:= irregular(2) [-2. 1 
ttl flag =:= irregular(l) ETS 
df =:= irregular (1) BESO EO 
dscp =:= irregular (6) ks Je 
ip_ecn_flags =:= irregular (2) [2.14 
ip_id =3= 

ip id enc dyn(ip id behavior outer.UVALUE) [ 0, 16 1; 
ttl hopl =:= 

static or irreg(ttl flag.UVALUE, 8) [ 0, 8 ]; 


} 


COMPRESSED ipv4_outer_without_ttl_irregular { 
ENFORCE (is_innermost == 0); 


ip_id = = 
ip id enc irreg(ip id behavior outer.UVALUE) [ 0, 16 l; 
dscp =:= static or irreg(ecn used.UVALUE, 6) [ 0, 6 17 
ip ecn flags =:= static or irreg(ecn used.UVALUE, 2) [ 0, 2 17 
ENFORCE (ttl irregular chain flag == 0); 
) 
COMPRESSED ipv4 outer with ttl irregular ( 
ENFORCE (is innermost == 0); 
ip id =;= 
ip id enc irreg(ip id behavior outer.UVALUE) ki Gaz 26. Je 
dscp =:= static or irreg(ecn used.UVALUE, 6) [ 0, 6 17 
ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 
ttl hopl =:= irregular(8) [ 8 1; 
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ENFORCE (ttl irregular chain flag == 1); 
} 


COMPRESSED ipv4_innermost_irregular { 


ENFORCE (is_innermost == 1); 
ip_id == 

ip id enc irreg(ip id behavior innermost.UVALUE) [ 0, 16 l; 
ENFORCE (ip inner ecn == ip ecn flags.UVALUE); 


} 
} 


AAA AAA LTL LL LTL ATA ATA AAT 
// TCP Options 
LILI LTL LL LTL LTL LTL LTL AAA 


// nbits is bound to the remaining length (in bits) of TCP 
// options, including the EOL type byte. 
tcp opt eol(nbits) 
{ 
UNCOMPRESSED { 


type =:= uncompressed_value(8, 0) [ 8 ]; 
padding =:= 
uncompressed value(nbits-8, 0) [ nbits-8 ]; 
) 
CONTROL { 


pad len [ 8 17 
) 


COMPRESSED eol list item ( 
pad len =:= compressed value(8, nbits-8) [ 8 ]; 


} 


COMPRESSED eol_irregular { 
pad_len =:= static; 
ENFORCE (nbits-8 == pad_len.UVALUE) ; 


} 


tcp_opt_nop 
{ 
UNCOMPRESSED { 
type =:= uncompressed_value(8, 1) [ 8 ]; 


} 


COMPRESSED nop_list_item { 
} 
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COMPRESSED nop irregular ( 
) 
) 


tcp opt mss 
{ 
UNCOMPRESSED { 


type =:= uncompressed_value(8, 2) [ 8 ]; 
length =:= uncompressed_value(8, 4) [ 8 ]; 
mss [ 16 ]; 
} 
COMPRESSED mss_list_item { 
mss =:= irregular(16) [ 16 ]; 
} 
COMPRESSED mss_irregular { 
mss =:= static; 
} 
} 
tcp_opt_wscale 
{ 
UNCOMPRESSED { 
type =:= uncompressed_value(8, 3) [ 8 ]; 
length =:= uncompressed_value(8, 3) [ 8 ]; 
wscale [ 8 1; 


} 


COMPRESSED wscale_list_item { 
wscale =:= irregular(8) [ 8 ]; 


} 


COMPRESSED wscale_irregular { 
wscale =:= static; 


} 


ts_lsb 
{ 
UNCOMPRESSED { 
tsval [ 32 ]; 
} 


COMPRESSED tsval_7 
discriminator =:= "0" 
tsval =:= lsb(7, -1) 


[ 1 1; 
nd 


r 
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COMPRESSED tsval 14 ( 
discriminator =:= “10” Ld iz 
tsval =:= 1sb(14, -1) [ 14 ]; 
} 


COMPRESSED tsval_21 { 
discriminator =:= “110” Ed li 
tsval =:= lsb(21, 0x00040000) [ 21 ]; 
} 


COMPRESSED tsval_2 { 


discriminator =:= “111” [ 3 1; 
tsval =:= lsb (29, 0x04000000) [ 29 1; 
} 
} 
tcp_opt_ts 


{ 
UNCOMPRESSED { 


type =:= uncompressed_value(8, 8) [ 8 ]; 
length =:= uncompressed_value(8, 10) [ 8 ]; 
tsval [ 32 ]; 
tsecho [ 32 ]; 
} 
COMPRESSED tsopt_list_item { 
tsval =:= irregular(32) [ 32 1; 
tsecho =:= irregular(32) [ 32 ]; 
} 
COMPRESSED tsopt_irregular { 
tsval =:= ts_lsb [ 8, 16, 24, 32 1; 
tsecho =:= ts_lsb [ 8, 16, 24, 32 1; 
} 
} 
sack pure lsb(base) 
{ 
UNCOMPRESSED { 
sack_field [ 32 ]; 
} 
CONTROL { 
ENFORCE (sack_field.CVALUE == (sack field.UVALUE - base)); 
) 
COMPRESSED lsb 15 ( 
ENFORCE (sack field.CVALUE == sack_field.CVALUE <= Ox7fff); 
discriminator =:= "0" kòt. Jå 
sack_field [ 15 ]; 
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} 


COMPRESSED lsb_22 { 


ENFORCE (sack field.CVALUE == sack field.CVALUE <= Ox3fffff); 
discriminator =:= “10” fr sey 
sack_field [ 22 ]; 


} 


COMPRESSED lsb_29 { 


ENFORCE (sack field.CVALUE == sack_field.CVALUE <= Oxlfffffff); 
discriminator =:= “110” Me 
sack field [ 29 1; 


} 


COMPRESSED full_offset { 
discriminator =:= “11111111” [ 8 15 
sack field [ 32 1; 


) 


sack block (reference) 
{ 

UNCOMPRESSED { 
block_start [ 32 ]; 
block_end [ 32 1; 

) 


COMPRESSED { 
block_start =:= 


sack_pure_lsb (reference) [ 16, 24, 32, 40 li; 
block end =;= 
sack pure lsb(block start.UVALUE) [ 16, 24, 32, 40 17 


) 


// The value of the parameter is set to the ack number value 
// of the TCP header 
tcp opt sack(ack value) 


( 


UNCOMPRESSED { 
type =:= uncompressed_value(8, 5) [ 8 ]; 
length [ 8 1; 
block_1 [ 64 ]; 
block_2 [ 0, 64 1; 
block_3 [ 0, 64 ]; 
block_4 [ 0, 64 1; 
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DEFAULT { 
length =:= static; 
block 2 =:= uncompressed value(0, 0); 
block 3 =:= uncompressed value(0, 0); 
block 4 =:= uncompressed value(0, 0); 


} 


COMPRESSED sackl list item | 


discriminator =:= "00000001"; 
block 1 =;= sack block(ack value); 
ENFORCE (length.UVALUE == 10); 


} 


COMPRESSED sack2_list_item { 


discriminator =:= "00000010"; 

block 1 =;= sack block(ack value); 

block 2 =;= sack block (block 1.UVALUE && OxXFFFFFFFF); 
ENFORCE (length.UVALUE == 18); 


} 


COMPRESSED sack3_list_item { 


discriminator =:= ’00000011’; 

block 1 =;= sack block(ack value); 

block 2 =;= sack block (block 1.UVALUE && OxXFFFFFFFF); 
block 3 =;= sack block (block 2.UVALUE && OxXFFFFFFFF); 
ENFORCE (length.UVALUE == 26); 


} 


COMPRESSED sack4_list_item { 


discriminator =:= "00000100"; 

block 1 =;= sack block(ack value); 

block 2 =;= sack block (block 1.UVALUE && OxFFFFFFFF); 
block 3 =;= sack block (block 2.UVALUE && OxXFFFFFFFF); 
block 4 =;= sack block (block 3.UVALUE 66 OxXFFFFFFFF); 
ENFORCE (length.UVALUE == 34); 


COMPRESSED sack_unchanged_irregular { 


discriminator =:= "00000000"; 
block 1 =;= static; 
block 2 =;= static; 
block 3 =;= static; 
block 4 =;= static; 


} 


COMPRESSED sackl_irregular { 
discriminator = ”00000001"; 
block 1 =;= sack block(ack value); 
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ENFORCE (length.UVALUE == 10); 
} 


COMPRESSED sack2_irregular { 


discriminator =:= "00000010"; 

block 1 =;= sack block(ack value); 

block 2 =;= sack block (block 1.UVALUE && OxFFFFFFFF); 
ENFORCE (length.UVALUE == 18); 


} 


COMPRESSED sack3_irregular { 
discriminator =:= ’00000011’; 


r 
block 1 =:= sack block(ack value); 
block 2 =;= sack block (block 1.UVALUE && OxFFFFFFFF); 
block 3 =;= sack block (block 1.UVALUE && OxFFFFFFFF); 
ENFORCE (length.UVALUE == 26); 


} 


COMPRESSED sack4_irregular { 


discriminator =:= "00000100"; 

block 1 =;= sack block(ack value); 

block 2 =;= sack block (block 1.UVALUE && OxXFFFFFFFF); 
block 3 =;= sack block (block 2.UVALUE && OxFFFFFFFF); 
block 4 =;= sack block (block 3.UVALUE 66 OxXFFFFFFFF); 
ENFORCE (length.UVALUE == 34); 


} 
} 


tcp_opt_sack_permitted 
{ 
UNCOMPRESSED { 


type =:= uncompressed_value(8, 4) [ 8 ]; 
length =:= uncompressed_value(8, 2) [ 8 ]; 
} 
COMPRESSED sack_permitted_list_item { 
} 
COMPRESSED sack_permitted_irregular { 
} 
} 
tcp_opt_generic 
{ 
UNCOMPRESSED ( 
type [ 8 1; 
length_msb =:= uncompressed_value (1, 0) [ 1 17 
length_lsb [ 7 1; 
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contents 

) 

CONTROL ( 
option_static [ 1 1; 

) 

DEFAULT ( 
type =:= static; 
length_lsb =:= static; 
contents =:= static; 


} 


} 


COMPRESSED generic_list_item { 


type =:= irregular (8) [ 8 ]; 
option_static =:= one_bit_choice EZ [RS 
length lsb =:= irregular(7) E d NS 
contents == 
irregular (length_1sb.UVALUE*8-16) [ length_1sb.UVALUE*8-16 ]; 


} 


// Used when context of option has option_static set to one 
COMPRESSED generic_static_irregular { 


ENFORCE (option_static.UVALUE == 1 
} 


// An item that can change, but currently is unchanged 
COMPRESSED generic_stable_irregular { 


discriminator =:= '11111111' [ 8 
ENFORCE (option_static.UVALUE == 
} 


// An item that is assumed to change constantly. 
// Length is not allowed to change here, 
// most likely to cause new NOPs or an EOL length change. 


COMPRESSED generic_full_irregular { 


)i 


li 
)i 


since a length change is 


discriminator =:= "00000000" Kd li 
contents == 
irregular (length_1sb.UVALUE*8-16) [ length_1sb.UVALUE*8-16 ]; 


ENFORCE (option_static.UVALUE == 
} 


tcp. list presence enc(presence) 


( 
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tcp_options; 


} 


)i 
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COMPRESSED list not present ( 
tcp options =:= static [ 0 l; 
ENFORCE (presence == 0); 

} 


COMPRESSED list_present { 
tcp_options =:= list_tcp_options [ VARIABLE ]; 
ENFORCE (presence == 1); 
} 
} 


VANN NNN NNN 
// TCP Header 
VANN NNN NNN 


port replicate(flags) 
{ 
UNCOMPRESSED { 
port [ 16 ]; 
} 


COMPRESSED port_static_enc { 
port =:= static [ 0 ]; 
ENFORCE (flags == 0b00); 

} 


COMPRESSED port_1sb8 { 
port =:= lsb(8, 64) [ 8 ]; 
ENFORCE (flags == 0b01); 

} 


COMPRESSED port_irr_enc { 
port =:= irregular(16) [ 16 ]; 
ENFORCE (flags == 0b10); 
} 
} 


tcp irreg ip ecn(ip inner ecn) 
{ 
UNCOMPRESSED { 
ip_ecn_flags [ 2 ]; 
} 


COMPRESSED ecn_present { 
// This field does not exist in the uncompressed header 
// and therefore cannot use uncompressed_value. 
ip_ecn_flags =:= 
compressed_value(2, ip_inner_ecn) [ 2 ]; 
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ENFORCE (ecn used.UVALUE == 1); 
) 


COMPRESSED ecn not present ( 
ip ecn flags =:= static [ 0 ]; 
ENFORCE (ecn used.UVALUE == 0); 


} 


rsf_index_enc 
{ 
UNCOMPRESSED { 
rsf_flag [ 3 ]; 
} 


COMPRESSED none { 
rsf_idx =:= "00" [ 2 ]; 
rsf_flag =:= uncompressed_value(3, 0x00); 


} 


COMPRESSED rst_only { 
rsf_idx =:= "01" [ 2]; 
rsf flag =:= uncompressed value(3, 0x04); 


} 


COMPRESSED syn_only { 
rsf_idx =:= "10" [2 19% 
rsf_flag uncompressed_value(3, 0x02); 


} 


COMPRESSED fin_only { 
rsf_idx =:= "11" [ 2 ]; 
rsf flag =:= uncompressed value(3, 0x01); 
) 
) 


optional 2bit padding(used flag) 
{ 
UNCOMPRESSED { 


} 


COMPRESSED used { 
padding =:= compressed_value(2, 0x0) [ 2 ]; 
ENFORCE (used_flag == 1); 

} 


COMPRESSED unused { 
padding =:= compressed_value(0, 0x0); 
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ENFORCE (used flag == 0); 


// ack stride value is the user-selected stride for scaling the 
// TCP ack number 
// ip inner ecn is the value bound when processing the innermost 
// IP header (ipv4 or ipv6 encoding method) 
tcp (payload size, ack stride value, ip inner ecn) 
{ 

UNCOMPRESSED { 


src_port [ 16 1; 
dst_port [ 16 ]; 
seq_number [ 32 ]; 
ack_number [ 32 ]; 
data_offset [ 4 ]; 
tcp_res_flags [ 4 ]; 
tcp_ecn_flags [ 2 1; 
urg_flag Edo ds 
ack_flag ET dz 
psh flag [ody 
rsf_flags Edu ditz 
window [ 16 ]; 
checksum [ 16 ]; 
urg_ptr [ 16 1; 
options [ (data offset.UVALUE-5)*32 ]; 
) 
CONTROL { 
dummy field s =:= field scaling(payload size, 
seq number scaled.UVALUE, seq number.UVALUE, 
seq number residue.UVALUE) [ 0 l; 
dummy field a =:= field scaling(ack stride.UVALUE, 
ack number scaled.UVALUE, ack number.UVALUE, 
ack number residue.UVALUE) [ 0 ]; 
ENFORCE (ack stride.UVALUE == ack stride value); 
} 
INITIAL { 
ack_stride =:= uncompressed_value(16, 0); 
) 
DEFAULT ( 
src_port =:= static; 
dst_port =:= static; 
seq_number =:= static; 
ack_number =:= static; 
data_offset =:= inferred_offset; 
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tcp_res_flags = 
tcp_ecn_flags 
urg_flag 
ack_flag 
rsf_flags 
window 
urg_ptr 
ack_stride 
ack_number_scaled 
seq_number_scaled 


ack_number_residue =:= 


seq_number_residue 


ROHC-TCP 


static; 
static; 
static; 


uncompressed_value(l, 
uncompressed_value (3, 


static; 
static; 


= static; 


static; 

static; 
static; 
static; 


1); 
0); 


January 2013 


} 


COMPRESSED tcp_static { 
src_port =:= irregular(16) [ 16 ]; 
dst_port =:= irregular(16) [ 16 ]; 


} 


COMPRESSED tcp_dynamic { 


ecn_used =:= one_bit_choice ee sy 
ack stride flag =:= irregular (1) E ZE ike 
ack_zero =:= irregular (1) KZ Ziz 
urp_zero =:= irregular (1) b ale Als 
tcp_res_flags =:= irregular (4) [ 4 ]; 
tcp_ecn_flags =:= irregular (2) [EZ IS 
urg_flag =:= irregular (1) E ide 
ack_flag =:= irregular (1) KZ ki? 
psh_flag =:= irregular (1) [ 1 1; 
rsf_flags =:= irregular (3) ki 303 
msn =:= irregular (16) [ 1601; 
seq number =:= irregular(32) [ 32 1; 
ack number =: 

zero_or_irreg(ack_zero.CVALUE, 32) 0;. 321% 
window =:= irregular(16) [ 16 ]; 
checksum =:= irregular(16) [ 16 ]; 
urg ptr == 

zero_or_irreg(urp_zero.CVALUE, 16) [ 0, 16 ]; 
ack_stride =:= 

static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 17 
options =:= list_tcp options [ VARIABLE |; 

) 
COMPRESSED tcp_replicate { 

reserved =:= "0" pk tij 
window presence =:= irregular(l) pe die 
list present =:= irregular(l) EE 
src port presence =:= irregular(2) E2 13 
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dst port presence =:= irregular (2) E 2: sg 
ack stride flag =:= irregular(l) pst de 
ack presence =:= irregular (1) ké A1; dg 
urp presence =:= irregular (1) FG 
urg flag =:= irregular(l) BA di 
ack_flag =:= irregular (1) EG ds 
psh_flag =:= irregular (1) BZ piz 
rsf_flags =:= rsf_index_enc MOKO 
ecn_used =:= one_bit_choice Ei Ts 
msn =:= irregular (16) [ 16 1; 
seg_number =:= irregular (32) [32 1; 
src port =;= 

port replicate(src port presence) [ 0, 8, 16 1; 
dst port =;= 

port replicate(dst port presence) [002 +84 160 ka 
window =:= 

static_or_irreg(window_presence, 16) 105 2160 1 
urg point =;= 

static or irreg(urp presence, 16) Ee 07 LOU 
ack_number =;= 

static or Sr presence, 32) E Gei 232 li 
ecn_padding =: 

optional_2bit Kadare (edh. used.CVALUE) [0 e bo 
tcp_res_flags =:= 

static or irreg(ecn used.CVALUE, 4) [ 0, 4 17 
tcp ecn flags =;= 

static or irreg(ecn used.CVALUE, 2) b ie, BE 
checksum =:= irregular (16) [ 16 ]; 
ack_stride = = 

static_or_irreg(ack_stride_flag.CVALUE, 16) lOs 16-13 
options == 

tcp. list presence enc(list present.CVALUE) [ VARIABLE ]; 

) 
COMPRESSED tcp irregular ( 

ip ecn flags =:= tcp irreg ip ecn(ip inner ecn) [ 0, 2 1; 
tcp res flags =:= 

static or irreg(ecn used.CVALUE, 4) [ 0, 4 ]; 
tcp ecn flags =:= 

static or irreg(ecn used.CVALUE, 2) B diz, Zo 
checksum =:= irregular (16) [ 16 ]; 


} 
AAA AAA AAA AAA AAA AAA TTT TTT TTT TTT TTT TTT TTT 


// Encoding methods used in compressed base headers 


III TTT TTT TTT OO OO TTT TTT 
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dscp_enc (flag) 
{ 
UNCOMPRESSED { 
dscp [ 61; 
) 


COMPRESSED static enc { 
dscp static [ 0 ]; 
ENFORCE (flag ); 

} 


COMPRESSED irreg { 

dscp := irregular (6) 
padding 
ENFORCE (flag 


)i 


) 


ip id lsb(behavior, k, p) 
{ 
UNCOMPRESSED { 
pta. [1016 l 


} 


CONTROL { 
ip_id_nbo [ 16 ]; 


} 


COMPRESSED nbo { 
ip_id_offset 
ENFORCE (behavior 


compressed_value (2, 


lsb(k, p) 
IP_ID_BEHAVIOR_SEQUENTIAL) ; 
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ug de 
0) [ 2 ] 


r 


[k 1; 


ENFORCE (ip id offset.UVALUE == ip id.UVALUE - msn.UVALUE); 


) 


COMPRESSED non nbo { 
ip id offset 
ENFORCE (behavior 
ENFORCE (ip id nbo.UVALU 


(ip id.UVALUE / 256) 


ENFORCE (ip id nbo.ULENGTH 


ENFORCE (ip id offset.UVALUE 


) 


optional ip id lsb(behavior, 
{ 
UNCOMPRESSED { 
ip_id [ 16 ]; 
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lsb(k, p) 
IP ID BEHAVIOR SEQUENTIAL SWAPPED) ; 


[k 1; 


o 
5 


+ (ip_id.UVALUE 256) * 256); 
16); 


ip_id_nbo.UVALUE - msn.UVALUE) ; 


indicator) 
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} 


COMPRESSED short { 


ip id =:= ip_id_lsb(behavior, 8, 3) [ 8 ]; 
ENFORCE ( (behavior == IP ID BEHAVIOR SEQUENTIAL) | | 

(behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED) ); 
ENFORCE (indicator == 0); 


} 


COMPRESSED long { 


ip id =:= irregular (16) [ 6 li, 

ENFORCE ( (behavior == IP ID BEHAVIOR SEQUENTIAL) | | 
(behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED) ); 

ENFORCE (indicator == 1); 

ENFORCE (ip id offset.UVALUE == ip id.UVALUE - msn.UVALUE); 


} 


COMPRESSED not_present { 
ENFORCE ( (behavior == IP ID BEHAVIOR RANDOM) | | 
(behavior == IP ID BEHAVIOR ZERO) ); 


) 
) 
dont fragment (version) 
{ 
UNCOMPRESSED ( 
df [1]; 
} 


COMPRESSED v4 { 
df =:= irregular (1) [ 1 ]; 
ENFORCE (version == 4); 

) 


COMPRESSED v6 ( 
df =:= compressed_value(1, 0) [ 1 1; 
ENFORCE (version == 6); 


} 
LITT TITT TITT TTT TTT TTT TTT 


// Actual start of compressed packet formats 

// Important note: 

// The base header is the compressed representation 
// of the innermost IP header AND the TCP header. 
AAA AAA KANARAN AAA TITS TITS TAT TTT 


// ttl_irregular_chain_flag is set by the user if the TIL/Hop Limit 
// of an outer header has changed. The same value must be passed as 
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// an argument to the ipv4/ipv6 encoding methods when extracting 
// the irregular chain items. 
co baseheader(payload size, ack stride value, 
ttl irregular chain flag, ip id behavior value) 
{ 
UNCOMPRESSED v4 { 


outer headers =:= baseheader outer headers [ VARIABLE |; 
version =:= uncompressed_value (4, 4) [ 4 1; 
header length =:= uncompressed_value (4, 5) [ 4 ]; 
dscp [ 6 1; 
ip_ecn_flags ki Azil 
length [ 16 ]; 
ip id [ 16 1; 
rf =:= uncompressed_value(1, 0) Lo ke ez 
df HE Zk hy 
mf =:= uncompressed_value(1, 0) [Lay 
frag_offset =:= uncompressed_value(13, 0) LAS 
ttl hopl [ 8 1; 
next_header agi 
checksum [ 16 ]; 
src_addr [ 32 ]; 
dest_addr [ 32 ]; 
extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 
src_port [ 16 ]; 
dest_port [ 16 1; 
seq number E 32.08 
ack number [ 32 1; 
data offset [Ar (lz 
tcp_res_flags [ 2 l 
tcp ecn flags [02 Jee 
urg flag PA de 
ack_flag [E 
psh_flag Hu d dre 
rsf_flags [Se AS 
window [ 16 1; 
tcp_checksum L 16: Té 
urg_ptr [ 16 1; 
options [ (data offset.UVALUE-5)*32 ]; 
} 
UNCOMPRESSED v6 { 
ENFORCE (ip id behavior innermost.UVALUE == IP ID BEHAVIOR RANDOM); 
outer headers =:= baseheader outer headers [ VARIABLE |; 
version =:= uncompressed value(4, 6) [ 4 17 
dscp [ 6 1; 
ip_ecn_flags bs J3 
flow label [ 20 1; 
payload length [ 16 ]; 


Pelletier, et al. Standards Track [Page 79] 


RFC 6846 ROHC-TCP January 2013 
next header [ 8 1; 
ttl hopl [ 8 1; 
src_addr [ 128 ]; 
dest_addr [ 128 ]; 
extension_headers := baseheader_extension_headers [ VARIABLE ]; 
src_port [ 16 1; 
dest_port [ 16 1; 
seq_number [ 32 ]; 
ack_number [ 32 ]; 
data_offset [2004 
tcp. res flags [ 4 1; 
tcp_ecn_flags [2 1; 
urg flag LL. 
ack_flag HZ dz 
psh_flag E GEO Mz 
rsf_flags Der AG 
window [ 16 ]; 
tcp_checksum [1603 
urg ptr [ 16 ]; 
options [ (data offset.UVALUE-5)*32 ]; 
df =:= uncompressed value(0,0) [ 0 1; 
ip id =:= uncompressed value(0,0) [ 0 1; 
) 
CONTROL { 
dummy_field_s =:= field scaling(payload size, 
seq number scaled.UVALUE, seq number.UVALUE, 
seq number residue.UVALUE) [ 0 l; 
dummy field a field scaling(ack stride.UVALUE, 
ack number scaled.UVALUE, ack number.UVALUE, 
ack number residue.UVALUE) [ 0 ]; 
ENFORCE (ack stride.UVALUE == ack stride value); 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value); 
} 
INITIAL { 


ack_stride 


} 


DEFAULT { 
tcp_ecn_flags 
data_offset 
tcp_res_flags 
rsf_flags 
dest_port 
dscp 
src_port 
urg_flag 
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uncompressed_value(16, 0); 


static; 

inferred_offset; 

static; 
uncompressed_value(3, 0); 
static; 

static; 

static; 
uncompressed_value (1, 0); 
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window =;= static; 
dest addr =;= static; 
version =;= static; 
ttl hopl =;= static; 
src addr =;= static; 
df =;= static; 
ack number =;= static; 
urg ptr =;= static; 
seq number =;= static; 
ack flag =:= uncompressed_value (1, 1); 


// The default for "options" is case 2) and 3) from 
// the list in Section 6.3.1 (i.e., nothing present in the 
// baseheader itself). 


payload_length =:= inferred ip v6 length; 

checksum =:= inferred ip v4 header checksum; 
length =:= inferred ip v4 length; 

flow label =:= static; 

next_header =:= static; 

ip_ecn_flags =:= static; 


// The tcp_checksum has no default, 
// it is considered a part of tcp_irregular 


ip_id_behavior_innermost =:= static; 
ecn_used =:= static; 
ack_stride =:= static; 
ack_number_scaled =:= static; 
seq_number_scaled =:= static; 
ack_number_residue =:= static; 


seq_number_residue =:= static; 
// Default is to have no TTL in irregular chain 
// Can only be nonzero if co_common is used 
ENFORCE (ttl irregular chain flag == 0); 

) 


LILI AAA AAA AAA AAA AAA AAA AA AAA AAA AAA TT LL TT 
// Common compressed packet format 


III LL 


COMPRESSED co common ( 
discriminator =;= “1111101” E få 
ttl hopl outer flag 


compressed_value(1, ttl irregular chain flag) [ 1 17 
ack flag =:= irregular(l) E Gu os 
psh_flag =:= irregular (1) [ 1 1; 
rsf_flags =:= rsf index enc E 22-14 
msn =:= lsb(4, 4) L:4 15 
seg_indicator =:= irregular (2) [ 2.]; 
ack_indicator =:= irregular (2) k2» 1 
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ack stride indicator =:= irregular (1) FA 
window_indicator =:= irregular (1) ei 3 
ip_id_indicator =:= irregular (1) DE da 
urg_ptr_present =:= irregular (1) [ 1 17 
reserved =:= compressed_value(1, 0) ab 
ecn_used =:= one_bit_choice FL d 
dscp_present =:= irregular (1) FG 
ttl hopl present =:= irregular(l) [aki dif 
list present =:= irregular(l) Eg 
ip id behavior innermost =:= irregular(2) EZ Jå 
urg flag =:= irregular(l) bu LTE 
df =:= dont fragment (version.UVALUE) EA JG 
header crc =:= Crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 1; 
seq number =;= 
variable length 32 enc(seq indicator.CVALUE) [ 0, 8, 16, 32 l; 
ack number =;= 
variable length 32 enc(ack indicator.CVALUE) [ 0, 8, 16, 32 17 
ack stride =;= 
static or irreg(ack stride indicator.CVALUE, 16) FO: LG Je 
window =:= 
static_or A indicator.CVALUE, 16) [ 0, 16 1; 
ip_id : 
optional_ip_id EEE id behavior innermost.UVALUE, 
ip id indicator.CVALUE) [ 0, 8, 16 1; 
urg ptr == 
static_or_irreg(urg_ptr_present.CVALUE, 16) [ 0, 16 ]; 
dscp =;= 
dscp enc(dscp | present. CVALUE) [ 0, 8 1; 
tt1_hopl =: 
static or irreg(ttl er  present.CVALUE, 8) [ 0, 8 1; 
options = 
tcp_list_presence_ cho (is spd CVALUE) [ VARIABLE 1; 
) 
// Send LSBs of sequence number 
COMPRESSED rnd 1 { 
discriminator =:= “101110” [ 6 1; 
seq_number =:= lsb(18, 65535) [ 18 ]; 
msn =:= lsb(4, 4) EG (e 
psh_flag =:= irregular (1) [ 1 1; 
header crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 1; 
ENFORCE ( (ip id behavior innermost .UVALUE == 
IP ID BEHAVIOR RANDOM) || 
(ip id behavior innermost.UVALUE == IP ID BEHAVIOR ZERO)); 


} 


// Send scaled sequence number LSBs 
COMPRESSED rnd_2 { 
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discriminator =;= "1100" [ 
seq number scaled =: lsb(4, 7) [ 
msn =: lsb(4, 4) [ 
[ 
[ 


ll 
eee 


psh flag =:= irregular (1) 
header crc =;= crc3(THIS.UVALUE, THIS.ULENGTH) 
ENFORCE (payload size != 0); 
ENFORCE ( (ip id behavior innermost .UVALUE 
IP ID BEHAVIOR RANDOM) || 
(ip id behavior innermost.UVALUE == IP ID BEHAVIOR ZERO)); 


se 


W bus db b 
ban jea jea ess 
se s 


} 


// Send acknowledgment number LSBs 
COMPRESSED rnd_3 { 
discriminator = 


ro! [ 1 
ack_number =:= lsb(15, 8191) [ 1 
msn =:= lsb(4, 4) [ 4 
[ 1 
3 


psh_flag =:= irregular (1) 
header crc =;= crc3(THIS.UVALUE, THIS.ULENGTH) 
ENFORCE ( (ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR RANDOM) | | 
(ip id behavior innermost.UVALUE == IP ID BEHAVIOR ZERO)); 
) 


// Send acknowledgment number scaled 
COMPRESSED rnd 4 ( 
discriminator =;= “1101” [ 
ack number scaled lsb(4, 3) [ 
msn lsb(4, 4) [ 
[ 
[ 


ll 
ll 
eee 


psh flag =:= irregular (1) 
header crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) 
ENFORCE (ack stride.UVALUE != 0); 
ENFORCE ( (ip id behavior innermost .UVALUE 
IP ID BEHAVIOR RANDOM) || 
(ip id behavior innermost.UVALUE == IP ID BEHAVIOR ZERO)); 


se 


W bus SS 
ban jea jea bean bea 
se s 


} 


// Send ACK and sequence number 
COMPRESSED rnd_5 { 
discriminator =:= “100” 
psh flag =:= irregular(l) 
msn =:= lsb(4, 4) 
header crc Bedi THIS.ULENGTH) 
seq_number lsb(14, 8191) 
ack_number =:= lsb(15, 8191) 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR RANDOM) | | 
(ip id behavior innermost.UVALUE == IP ID BEHAVIOR ZERO)); 


ba ba WB Ww 
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// Send both ACK and scaled sequence number LSBs 


COMPRESSED rnd 6 { 


January 2013 


discriminator =;= '1010’ [324° 15 
header crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 1; 
psh flag =:= irregular(l) Ci; 
ack_number =:= lsb(16, 16383) [ 16 1; 
msn =;= lsb(4, 4) [ 4 ]; 
seq_number_scaled =:= lsb(4, 7) D d iz 
ENFORCE (payload_size != 0); 
ENFORCE ((ip id behavior innermost.UVALUE == 

IP ID BEHAVIOR RANDOM) || 

(ip id behavior innermost.UVALUE == IP ID BEHAVIOR ZERO)); 


) 


// Send ACK and window 


COMPRESSED rnd 7 { 


discriminator =:= 
ack number 


window 
msn 


psh flag 


header 
ENFORCE 


} 


// An extended packet type for seldom-changing fields 
// Can send LSBs of TTL, RSF flags, 
// options list 

COMPRESSED rnd 8 l 


cre 


(ip id behavior innermost.UVALUE 


"TOLL 


1sb(18, 


65535) 


irregular (16) 


1sb (4, 


4) 


irregular (1) 

crc3(THIS.UVALUE, THIS.ULENGTH) 

((ip id! behavior- innermost .UVALUE == 
IP_ID_BEHAVIOR_RANDOM) || 


[ 
[ 
[ 
[ 
[ 
[ 


== IP ID BEHAVIOR ZERO)); 


change ECN behavior, and 


discriminator =:= '10110' E Seis 
rsf_flags =:= rsf_index_enc [2015 
list present =:= irregular (1) Ed 
header crc =:= Crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 
msn =:= lsb(4, 4) [ 4 ]; 
psh_flag =:= irregular (1) Edo ls 
tt1_hopl =:= lsb(3, 3) LES 
ecn_used =:= one_bit_choice ENE BE 
seg_number =:= lsb(16, 65535) E OG be 
ack_number = i= Sea 16383) [ 16 ]; 
options == 
tcp. list presence enc(list present.CVALUE) [ VARIABLE 1; 

ENFORCE ( (ip id behavior innermost.UVALUE == 

IP ID BEHAVIOR RANDOM) || 

(ip id behavior innermost.UVALUE == IP ID BEHAVIOR ZERO)); 
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// Send LSBs of sequence number 
COMPRESSED seq 1 { 


discriminator =:= “1010” E dk JG 
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 
seq_number =:= lsb(16, 32767) [ 16 1; 
msn =:= lsb(4, 4) [4]; 
psh_flag =:= irregular (1) [ 1 1; 
header crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [3 J? 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 
} 
// Send scaled sequence number LSBs 
COMPRESSED seq_2 { 
discriminator =;= "11010" bobs JG 
ip id =;= 
ip id lsb(ip id behavior innermost.UVALUE, 7, 3) kt SA APEZ 
seq number scaled =:= lsb(4, 7) [ 4 1; 
msn =;= HOE 4) Edd 
psh_flag =:= irregular (1) E des 
header crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 1; 
ENFORCE (payload size != 0); 
ENFORCE ( (ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 
) 
// Send acknowledgment number LSBs 
COMPRESSED seq 3 { 
discriminator =:= “1001” [ 4 ]; 
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 
ack_number =:= lsb(16, 16383) [ 461; 
msn =;= lsb(4, 4) kal; 
psh flag =:= irregular(l) [ 1 1; 
header crc =:= Crc3 (THIS.UVALUE, THIS.ULENGTH) MEN 
ENFORCE ((ip id. behavior- innermost .UVALUE == 
IP_ID_BEHAVIOR_SEQUENTIAL) || 
(ip_id_behavior_innermost.UVALUE == 
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 
} 
// Send scaled acknowledgment number scaled 
COMPRESSED seq_4 { 
discriminator = "0" [A li 
ack number scaled =:= lsb(4, 3) [: 4: Je 
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// Due to having very few ip_id bits, 


ip id =:= ip id lsb(ip id behavior innermost.UVALUE, 3, 
msn =:= lsb(4, 4) [ 
psh flag =:= irregular(l) [ 

[ 


header crc =:= crc3(THIS.UVALUE, 

ENFORCE (ack_stride.UVALUE != 0); 

ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 


THIS.ULENGTH) 


) 


// Send ACK and sequence number 
COMPRESSED seq 5 { 


discriminator =:= “1000” 

ip id =:= ip id lsb(ip id behavior innermost.UVALUE, 4, 
ack number =:= lsb(16, 16383) 

seq number =:= lsb(16, 32767) 

msn =:= lsb(4, 4) 

psh_flag =:= irregular (1) 


header crc =:= crc3 (THIS.UVALUE, THIS. 

ENFORCE ((ip id behavior innermost.UVALUE 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 


ULENGTH) 


) 


// Send both ACK and 
COMPRESSED seq 6 { 


scaled sequence number LSBs 


discriminator =;= “11011” 

seq_number_scaled =:= lsb(4, 7) 

ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 7, 
ack_number =:= lsb(16, 16383) 

msn =:= lsb(4, 4) 

psh_flag =:= irregular (1) 


header crc =:= crc3(THIS.UVALUE, 

ENFORCE (payload_size != 0); 

ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 


THIS.ULENGTH) 


} 


// Send ACK and window 
COMPRESSED seq_7 { 


discriminator =:= ’1100’ 
window =:= lsb(15, 16383) 
ip id =:= ip id lsb(ip id behavior innermost.UVALUE, 5, 
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ack number =:= lsb(16, 32767) [ 16 ]; 
msn =:= lsb(4, 4) [ 41; 
psh flag =:= irregular(l) E ZK. deg 
header crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) LoS Ts 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 
} 
// An extended packet type for seldom-changing fields 
// Can send LSBs of TTL, RSF flags, change ECN behavior, and 
// options list 
COMPRESSED seq_8 { 
discriminator =:= “1011” [ 4 de 
ip id =:= ip id lsb(ip id behavior innermost.UVALUE, 4, 3) [ 4 ]; 
list present =:= irregular (1) [AL IG 
header crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 
msn =:= lsb(4, 4) [ 41; 
psh flag =:= irregular(l) FAG 
ttl hopl =:= lsb(3, 3) [ 3 1; 
ecn used =:= one bit choice ee A 
ack number =;= lsb(15, 8191) [15514 
rsf flags =;= rsf index enc LG Hg 
seq_number =:= lsb(14, 8191) [ 14 ]; 
options = = 
tcp. list presence enc(list present.CVALUE) [ VARIABLE |; 


ENFORCE ( (ip id behavior innermost .UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)); 
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8.3. Feedback Formats and Options 
8.3.1. Feedback Formats 


This section describes the feedback formats for the ROHC-TCP profile, 
following the general ROHC feedback format described in Section 5.2.4 
of [RFC5795]. 


All feedback formats carry a field labeled MSN. The MSN field 
contains LSBs of the MSN control field described in Section 6.1.1. 
The sequence number to use is the MSN corresponding to the last 
header that was successfully CRC-8 validated or CRC verified. 


FEEDBACK-1 

GO Be San d IB SÈ Lo 
4+---+---4---+---4---+---4---+---+ 
| MSN | 
4+---4+---4---+---4---+---4---+---+ 


MSN: The LSB-encoded master sequence number. 


A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, 
FEEDBACK-2 must be used. 


FEEDBACK-2 


0 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 


|Acktype | MSN 

+---+---+---+---+---+---+---+---+ 
| MSN | 
+---+---+---+---+---+---+---+---+ 
| CRC | 
+---+---+---+---+---+---+---+---+ 
4 Feedback options / 


4+---4---4---4---+4---+---+4---+---+ 


Acktype: 
0 = ACK 
1 = NACK 


2 = STATIC-NACK 


3 is reserved (MUST NOT be used for parsability) 
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MSN: The LSB-encoded master sequence number. 


CRC: 8-bit CRC computed over the entire feedback element (as 
defined in Section 5.3.1.1 of [RFC5795]). For the purpose of 
computing the CRC, the CRC field is zero. The CRC is calculated 
using the polynomial defined in [RFC5795]. 


Feedback options: A variable number of feedback options, see 
Section 8.3.2. Options may appear in any order. 


A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an 
acknowledgment for a successfully decompressed packet, which packet 
corresponds to the MSN of the feedback element, unless the MSN-NOT- 
VALID option (Section 8.3.2.2) appears in the feedback element. 


The FEEDBACK-2 format always carries a CRC and is thus more robust 
than the FEEDBACK-1 format. When receiving FEEDBACK-2, the 
compressor MUST verify the information by computing the CRC and by 
comparing the result with the CRC carried in the feedback format. If 
the two are not identical, the feedback element MUST be discarded. 


8.3.2. Feedback Options 


A ROHC-TCP feedback option has variable length and the following 
general format: 


0 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
| Opt Type | Opt Len | 
+---+---+---+---+---+---+---+---+ 
/ option data / Opt Length (octets) 
+---+---+---+---+---+---+---+---+ 


Each ROHC-TCP feedback option can appear at most once within a 
FEEDBACK-2. 


8.3.2.1. The REJECT Option 


The REJECT option informs the compressor that the decompressor does 
not have sufficient resources to handle the flow. 


Ha a a A A A 


| Opt Type = 2 | Opt Len = 0 | 
+---+---+---+---+---+---+---+---+ 
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When receiving a REJECT option, the compressor MUST stop compressing 
the packet flow, and SHOULD refrain from attempting to increase the 
number of compressed packet flows for some time. The REJECT option 
MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, 
the compressor MUST discard the entire feedback element. 


8.3.2.2. The MSN-NOT-VALID Option 


The MSN-NOT-VALID option indicates that the MSN of the feedback is 
not valid. 


+---+---+---+---+---+---+---+---+ 
| Opt Type = 3 | Opt Len = 0 | 
+---+---+---+---+---+---+---+---+ 


A compressor MUST ignore the MSN of the feedback element when this 
option is present. Consequently, a NACK or a STATIC-NACK feedback 
type sent with the MSN-NOT-VALID option is equivalent to a STATIC- 
NACK with respect to the semantics of the feedback message. 


The MSN-NOT-VALID option MUST NOT appear more than once in the 
FEEDBACK-2 format and MUST NOT appear in the same feedback element as 
the MSN option; otherwise, the compressor MUST discard the entire 
feedback element. 

8.3.2.3. The MSN Option 
The MSN option provides 2 additional bits of MSN. 


Ha a a A A A 


| Opt Type = 4 | Opt Len=1 | 
EEE 
| MSN | Reserved 


+---+---+---+---+---+---+---+---+ 


These 2 bits are the least significant bits of the MSN and are thus 
concatenated with the 14 bits already present in the FEEDBACK-2 
format. 


The MSN option MUST NOT appear more than once in the FEEDBACK-2 
format and MUST NOT appear in the same feedback element as the MSN- 
NOT-VALID option; otherwise, the compressor MUST discard the entire 
feedback element. 
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8.3.2.4. The CONTEXT MEMORY Feedback Option 


The CONTEXT MEMORY option means that the decompressor does not have 
sufficient memory resources to handle the context of the packet flow, 
as the flow is currently compressed. 


0 1 2 3 4 5 6 a 
+---+---+---+---+---+---+---+---+ 
| Opt Type = 9 | Opt Len = 0 | 
+---+---+---+---+---+---+---+---+ 


When receiving a CONTEXT_MEMORY option, the compressor SHOULD take 
actions to compress the packet flow in a way that requires less 
decompressor memory resources, or stop compressing the packet flow. 


The CONTEXT_MEMORY option MUST NOT appear more than once in the 
FEEDBACK-2 format; otherwise, the compressor MUST discard the entire 
feedback element. 


8.3.2.5. Unknown Option Types 


If an option type unknown to the compressor is encountered, the 
compressor MUST continue parsing the rest of the FEEDBACK element, 
which is possible since the length of the option is explicit, but 
MUST otherwise ignore the unknown option. 


9. Changes from RFC 4996 


This RFC revises RFC 4996. It is mostly backwards-compatible with 
RFC 4996, except for two cases that did not interoperate as described 
below. 


9.1. Functional Changes 


O The SACK option compression in [RFC4996] assumed that multiple 
SACK blocks within the same option would be in sorted order so 
that the block starts were LSB-encoded from the end of the 
previous block. This meant that SACK blocks that are not in 
sorted order could be impossible to compress in some cases. 
Therefore, the SACK compression in the formal notation has changed 
and therefore also the bits-on-the-wire. 


O The ESP NULL header compression has been deprecated due to 
interoperability problems with needing to know information from 
the trailer. The ESP NULL compression was already removed from 
ROHCv2 [RFC5225] for the same reason and it was considered better 
to remove it from this profile rather than try to fix the 
interoperability issue. 
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2. Non-functional Changes 


o The way sequential IP-ID compression was described in the FN code 
was incorrect and the code used for ROHCv2 [RFC5225] has been 
imported into this specification (e.g., offset is made into a 
global control field). This does not change the bits-on-the-wire. 
The only change is how this encoding is described in the formal 
notation, not how the compression occurs. 


o Default encoding for the ”df” and "ip id” fields have been added 
for IPv6 with O-bit uncompressed format to clarify that these 
never appear in IPv6. 


o The scaled encoding of the Acknowledgment Number and Sequence 
Number were incorrectly described in the FN code in [RFC4996] and 
have been updated in the same style as in ROHCv2 [RFC5225]. This 
does not change the bits-on-the-wire, only the way the compression 
is described in the FN code. 


o The external arguments to ipv4 and co_baseheader have been 
updated. This is again only a change for FN correctness and does 
not affect interoperability. 


o Errata for [RFC4996] related to minor errors in the FN and textual 
errors have also been corrected. 


Security Considerations 


A malfunctioning or malicious header compressor could cause the 
header decompressor to reconstitute packets that do not match the 
original packets but still have valid IP and TCP headers, and 
possibly also valid TCP checksums. Such corruption may be detected 
with end-to-end authentication and integrity mechanisms that will not 
be affected by the compression. Moreover, this header compression 
scheme uses an internal checksum for verification of reconstructed 
headers. This reduces the probability of producing decompressed 
headers not matching the original ones without this being noticed. 


Denial-of-service attacks are possible if an intruder can introduce 
(for example) bogus IR, CO, or FEEDBACK packets onto the link and 
thereby cause compression efficiency to be reduced. However, an 
intruder having the ability to inject arbitrary packets at the link 
layer in this manner raises additional security issues that dwarf 
those related to the use of header compression. 
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11. IANA Considerations 


The reference for the ROHC profile identifier 0x0006 has been updated 
to reference this document instead of RFC 4996. 


A ROHC profile identifier has been reserved by IANA for the profile 
defined in this document. Profiles 0x0000-0x0005 have previously 
been reserved; this profile is 0x0006. As for previous ROHC 
profiles, profile numbers Oxnn06 have been reserved for future 
updates of this profile. 


Profile Usage Document 
identifier 

0x0006 ROHC TCP [RFC6846] 
Oxnn06 Reserved 
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